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[57] ABSTRACT 

A hand-held data storage unit which transfers data from a 
computer to the unit by means of a graphical user interface 
in the computer controlled by the hand-held data storage 
unit. 
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DATA MOUSE from one computer system to another computer system or 

between a computer system and a stand-alone device, such 

BACKGROUND OF THE INVENTION as an automat ic teller machine, a stand-alone disk storage 

1. Field of the Invention unit, an automatic controller, or other devices without a 
This invention relates to a portable, hand-held, device for s graphical user interface. 

transferring data to and from a data processing system via a Another object of the invention is to provide a portable 

graphical user interface, and, more particularly, to a hand- hand-held device for transferring data between systems 

held data storage device that generates graphical user input without the need for special user input commands, 

signals to facilitate data transfer. Briefly, this invention contemplates the provision of a 

2. Description of the Prior Art 10 hand-held data storage unit which transfers data from a 
In the prior art, there are a variety of devices and networks computer to the unit by means of a graphical user interface 

to move data from one data processing system (e.g., a in ^ computer controlled by the hand-held data storage 
personal computer system) to another data processing sys- unil - ln a Purred embodiment of the invention, a wireless 
tern. These include diskettes (e.g., magnetic and optical), _ communication link provides two-way communication 
local area hardwired networks, various wireless transmis- 15 between the computer and the hand-held data storage unit, 
sion networks, and semi-conductor memory cards. The computer's graphic user interface is expanded to pro- 
More specifically to this invention, U.S. Pat. No. 4,102, Vlde an icon that ^nsfers data to a hand-held data storage 
493 issued to Moreno et al. (Moreno '493) describes a um < m P°f e f a P°f° n controlled b ^ he 
method and apparatus for transporting data from one device 20 hand " h f eld data storage unit Data compression and/or 
to another. In Moreno '493, data fe transferred from a encr yP tlon ™% b * ™™* d ^ ^ computer m response to 

j ■ t j i an icon controlled by the hand-held unit prior to transfer and 

processor system to a portable card m which data is elec- auivuuwuwuiwu uy UHHiauu uwu 

ironically stored, modified, and transferred to another pro- stora § e in me uml ' . t . 

cessor system. Moreno '493 transports data by means of a A hand-held data storage unit in accordance with this 

hand-held device, but the device does not provide a user 25 invention controls a CRT pointer m a similar fashion to a 

interface to facilitate the transfer (upload or download) of trackba11 or other P ointin S device attac hed t0 a computer 

the data system having a graphical user interface. One frequently 

U.S. Pat. No. 4,125,871, issued Nov. 14, 1987, to Mania used ,? atl radiation operation is a so-called "cut and 

et al. (Martin '871) describes a portable data entry device in °^ Tatim , ™ c opeT ^ 0n °. f ^ pa f, * qUlt6 

,. , v , j « wu ' * a ■« ,w M t,-i useful and simple to use within a single system. But it a user 

which a user keys in data, which is stored in the device until 30 . / j « * » * 

... . ,1 j t * 1 j j * * * „ wants to cut from one computer system and paste to 

a later time when the data is uploaded to a computer system. . . . •r *- u*u* P^ 

™ . ti -t j ♦ j • • u 11 ♦ • a „ another computer system, information has to be transferred 

The portable data entry device is wholly contained within a „ , ^ .1 . . v T A v T 

u i_ ■ rp« j » • 1 j 1 ♦ ■ to diskette or other portable media, or perhaps sent by LAN 

small housing. The device includes an electronic memory „ MM " ■ * ; n u *u 

r 4 • 1 1 1 u * a or WAN since poor art pointer controllers, such as the 

capable of storing a plurality of multiple character records 1 . « j ,t_ • * * t *u a a 

j . , . 11 ui fit • mouse, trackballs, and other pointer control methods, do not 

and includes manually operable controls tor sequencing 35 , iU ' * j * tu • u u a 

, iL c • 1 j « * c - i have the ability to transport data. The invention here embod- 

throueh the memory for review and updating or previously * t_-v„ j ^ * * u-r* 

» j * a * * a a *L u • u.. ied by virtue of its portability and data storage ability in 

entered data. A connector is provided on the housing by -*u •* • * * 1 j l- a 

, J , , . , . ' combination with its pointer control and combined with an 

which the device can be directly connected to a data system . r . . A , . , 

for the readout of the stored data. Hie device is self powered W«°prute .con representat.on associated wtth the graphed 

and contains circuitry operative to conserve available ener- 40 T ,nt f rfaC i pennltS a Very , Simp1 , 6 meth °l ° f ,. cu 

17 r information from one computer system and "pasting this 

gizing power. . ^ 4 , same information on another computer system. 

U.S. Pat. No. 4,689,757, issued to Downing et al. 

(Downing '757), describes an apparatus for transporting BRIEF DESCRIPTION OF THE DRAWINGS 

information captured at a coin counter to a computer. The The foregoing and other objects, aspects and advantages 

system is comprised of a discrete machine event counting 45 will be better understood from the following detailed 

module which records and stores a count of machine opera- description of a preferred embodiment of the invention with 

tion and can include means for recording the time of some reference to the drawings, in which: 

selected event or events. The module also stores an identi- pIG. 1 shows schematically an overview of the preferred 

fication code for the particular machine. The module can be embodiment and particularly shows a hand-held data storage 

connected directly through a microprocessor to a central 50 deyice hnked yia wireless commurjicatio n channel to a 

processing center, or it can be located at a machine or at a computer 

group of machines. FIG. 2 shows an exemplary view of the computer screen 

The transfer unit can then be transported to access means when lhe mvemion described herein is not linked to the 

for the central processing center and the information that computer 

was obtained from the module will be transferred to centers 55 ^ ^ exemplary yiew of the computer ^nen 

for processing and tabulation. when the mvention described herein is linked to the com- 

Of course, graphical user interfaces which allow a user to p Uter 

generate computer commands by means of a graphical icon FIG 4 ^ a Mock ^ m of Qoe embodiment of the 

display and display pointer are well known ^^delyuscd inve nUon described herein. 

in the art (see, for example, U.S. Pat. No. 5,204,947 and the 60 _ , , t , t . . . _ - , . - 

. . v r ' « . . v vt a . j- • .l FIG. 5 shows detail of certain internal logic 01 the 

materials referenced therein). Notwithstanding, in the prior ... c „ T _ A 

^ 4l _ V i_i • 1 1 • * embodiment of FIG. 4. 

art there is no generally applicable, simple way to transfer ^ • _r r 

, t „ , „ FIG. 6 shows a block diagram of a computer interface for 

data among diverse systems. . 

the preferred embodiment. 

SUMMARY OF THE INVENTION 65 FIGS 7 and 8 are hi g h level flow diagrams of interrupt 

An object of this invention is the provision of a handheld, handling structure and execution structure of the firmware 

portable device to facilitate user operation in moving data associated with a preferred embodiment of the invention. 



11/06/2003, EAST Version: 1.4.1 



6,12 

3 

DETAILED DESCRIPTION. OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

Turning now to the invention in greater detail, FIG. 1 
illustrates a preferred embodiment in which a hand-held data 
storage unit 10 is wirelessly coupled (e.g., low power 
electromagnetic ("radio") waves 14) to a computer indicated 
at 17, equipped with graphical user interface software, such 
as that supported by the IBM OS2 operating system. The use 
of radio waves allows greater freedom of placement for the 
unit 10, thus greater freedom and ease of use for the user. 
Wireless optical communication links 15 and hardwired 
communications links 13 may be used also, if desired. A 
standard mouse configuration is shown, with two "clicker" 
buttons 11, 12 and a mouse ball assembly 32. Additional 
buttons can be supported if necessary, as can additional 
controls. The computer 17 has a display screen 20 and 
additional hardware 18 to communicate with hand-held data 
storage unit 10. In the preferred embodiment, hardware 18 
is connected via serial cable 19 to computer 17. Thus, 
handheld data storage unit 10 is (insofar as being a pointing 
device) similar in its operation to a standard serial mouse. 

FIG. 2 illustrates pictorially display screen 20 associated 
with computer 17. It has a special icon 22 for supporting the 
hand-held data storage unit 10 and a universal symbol 21 to 
indicate when unit 10 is not in communication with proces- 
sor 17. 

FIG. 3 illustrates a typical computer screen 20 that has an 
icon 22 supporting the hand-held data storage unit 10 where 
the unit is coupled to computer 17. State information 23 is 
displayed that indicates how much memory capacity has 
been used in the unit 10. Unit 10 is coupled to the computer 
17 when communication between it and computer 17 is 
established. If a standard mouse is attached to the computer, 
icon 22 would be displayed with an appropriate symbol, 
such as the letter "M", to signify an attached standard 
mouse. Alternatively, other icon images could be displayed 
to signify the connection of a standard mouse. 

A block diagram of the hand-held data transfer unit 10 is 
shown in FIG. 4. A one-chip processor indicated by the 
general reference number 30 with onboard CPU 37, RAM 
38, program storage 40, input/out capability 39, and serial 
port 41 interfaces through logic 31 to the left mouse button 
11, right mouse button 12, and with the mouse ball assembly 
32. A storage unit 33 external to processor 30 and coupled 
thereto by bus 45 is provided to store data. Typically, with 
currently available components, storage unit 33 would con- 
tain about 60K bytes of SRAM. However, as storage com- 
ponent technology advances, the anticipated size of the 
storage unit 33 will become larger. 

In this preferred embodiment, a transceiver 34 transmits 
and receives radio frequency signals (indicated graphically 
at 14) coupling the unit 10 to computer 17 via interface 18. 

Alternative wireless coupling indicated at 15 and hard 
wired coupling indicated at 13 are also practicable. A serial 
data stream from the processor 30 via serial port 41 and 
connection 42 modulates a radio frequency carrier signal of 
transceiver 34. Similarly, a modulated signal received from 
computer 17 is demodulated by circuit 34 and received as a 
serial data stream by processor 30 via serial port 41. Power 
is provided by a battery 35, with due consideration of power 
consumption by processor 30, logic 31, and storage 33 
which should all be CMOS or equivalent low power logic. 
In addition, a processor 30 "sleep" mode is used in this 
preferred embodiment. 

The logic 31 in FIG. 4 has multiple wire connections 44 
to processor 30. This logic 31 also has multiple wire 
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connections 43 to mouse ball assembly 32. The logic 31 has 
an external interrupt signal wire 36 to an interrupt pin 46 of 
the processor 30. An interrupt signal on wire 36 is an event 
which causes processor 30 to awaken from its "sleep" mode. 

5 FIG. 5 shows a typical implementation of logic 31. This 
implementation allows serial port 41 to operate at a maxi- 
mum practical rate. Therefore, the load on processor 30, 
which would be incurred should processor 30 be required to 
poll button 11, 12 and mouse ball assembly 32 for activity, 

1° is reduced while also facilitating the use of processor 30 
"sleep" mode. 

FIG. 5 shows the logic to reduce the load on processor 30 
and to reduce the power consumption of unit 10. It uses 
counters 58 and 59 coupled by leads 56 and 57 to revolution 

15 pulse generators 55 (X) and 54 (Y) coupled to a mouse ball 
61. Counters 58 and 59 are up/down counters, with output 
signals on lines 62 being emitted when the counter is in a 
non-zero state. These counters keep track of mouse ball 61 
movement even while processor 30 is busy with other tasks. 

20 Reading counters 58 or 59 via a bus 53 results in the 
respective counters being reset to a zero state. Read, chip 
select, and addressing signals are represented by wires 52, 
which are a subset of wires 44. Logic circuit 60 debounces 
and detects a state change of button 11 and button 12; a state 

25 change for either button results in a signal on line 63 being 
emitted. This signal 63 is combined via logic 64 with signals 
62 emitted by counter 58 and 59. The resulting signal 
emitted by logic 64 is applied to wire 36 as an interrupt to 
processor 30. The debounced change of state of buttons 11 

30 and 12 are also outputted on leads 50 and 51 

FIG. 6 is a block diagram of the interface module 18. In 
transmitting data to the unit 10 from the computer 17, a 
serial data stream received via serial cable 19 modulates a 

35 radio frequency carrier generated by an oscillator 82. An rf 
link 81 couples the modulated carrier signal to a transceiver 
80 which transmits the signal to the unit 10. In transmitting 
data from the unit 10 to the computer 17, the signal received 
from unit 10 is demodulated by transceiver 80 and the 

4Q demodulated serial data stream is sent to computer 17 via 
serial cable 19. Power for the transceiver 80 is taken from 
the serial cable 19, as only a very low power output radio 
frequency signal is desired or required. 

An example of a command set for the hand -he Id data 

45 transfer unit 10 is: 



DIRECTORY-provides a list of the data currently preserved in 
Data Mouse and the free space available. By implication, 
50 this also provides the size of the Data Mouse total memory. 
Name/location/size/chain/ . . , /name/location/size/chain/ 
freesize/EOF 

Return codes: 

•command successful 
•command not understood 
55 •storage error 

COPY <DM->C> or <C->DM> 

Command to copy data to the portable device 10 or copy data 
from the portable device 10 
Return codes: 

•command successful 
•command not understood 

60 

•storage error 

•insufficient space, command not done 
ERASE <name> 
(note: degenerate form of copy-copy over a name with 
length 0) 
Return codes: 
65 •command successful 

•command not understood 
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-continued 



•storage error 

•insufficient space, command not done 
FORMAT S 
Clear the data stored in portable device 10 
Note that the GUI support should inquire "Are You Sure". 
Return codes: 

•command successful 
•command not understood 

•storage error 10 
DIAG <mode<,subcommand» 
Execute diagnostics, two modes, one clears memory and one 
does not, with subcommands 
Return codes: 
•command successful 

•command not understood 15 
•storage error 

•processor ROM checksum failure 
•processor RAM checksum failure 
•other logic error (actually, several) 
ACTION <SQUEEK|BUNrKjTWTTCH> 

(optional, based on capability of DM, preferred embodiment 
does not show the hardware to support this capability) 
Return codes: 

•command successful 
•command not understood 



20 



FIGS. 7 and 8 are high level flow charts for certain of the 
operations of processor 30. The firmware to carry out these 
operations is coded in permanent storage element 40 
(ROM). 

FIG. 7 is the interrupt handling micro code flow. An 
interrupt, either IRQ 46 or from the serial port 41, initiates 
interrupt handling. Decision 110 determines if the event is a 
change of state of buttons 11 or 12; this is done by examining 
information received via I/O port 39 in particular, the lines 
from logic 44 as compared with the preserved last state of 
the buttons as preserved in processor RAM 38 of processor 
30. If the event is a change of state of one of the buttons 11 
or 12, further processing is done by finalizing the debounce 
of the buttons as shown by block 111, verifying continued 
presence in block 112, and, if the change of state is 
confirmed, making the appropriate state variable changes as 
indicated by block 113. If the event was not a change of state 
of a button or the change of state of a button or buttons has 
been handled, then control is passed to a decision block 120 
to determine if there has been movement of the mouse ball 
61. If so, the appropriate information is gathered and states 
changes as shown by block 121. If the preceding blocks have 
completed, a check is made at block 130 to see if serial port 
41 has generated an interrupt indicating the completion of 
transmission or reception of data. If so, the data is collected 
(if data is being received) or, if necessary, additional data is 
written to the serial port (if transmission) as represented by 
block 131. After completing the aforementioned, interrupt 
handling is completed and the routine exits as shown by 
block 140. The state information generated by blocks 113, 
121 and 131 is used by the general execution code to 
manipulate data or modify hardware as necessary. 

Note that the description of interrupt handling is from a 
very high level and minor details not necessary to elucidate 
operation are not shown — for example, the preservation of 
registers upon entry to the interrupt handling routine, and a 
check for additional pending interrupts prior to exit via 
block 140 among other details. 

Of particular interest is the use of the interrupt to awaken 
from power conserving "sleep" mode. Referring now to 
FIG. 8, the hand-held data storage unit 10, when not linked 
to a computing system or other device, would reside in 
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"sleep" mode as represented at 201. An interrupt, as 
described in connection with FIG. 7, awakens processor 30 
from its "sleep" mode. After processor 30 completes han- 
dling the interrupt (block 202), processor 30 initiates an 
action to check for a link to computer 17 (for example, at 
block 200). If no such link is present, processor 30 returns 
to its sleep mode of operation (block 201). If there is a link 
connection to the computing system, processor 30 replies to 
the computing system request with "I'm alive" status (block 
110). Next, in block 220, the processor 30 checks to see if 
any action is to be taken. Actions would be represented by 
changes to state variables as might be done by blocks 113, 
121, 131 of FIG. 7, including the reception of an external 
request (via serial port 41, represented in FIG. 7 by block 
131). The processor 30 handles any required action at block 
230. If there is action is to be taken, there was possibly an 
error on the link. 

While the invention has been described in terms of a 
single preferred embodiment, those skilled in the art will 
recognize that the invention can be practiced with modifi- 
cation within the spirit and scope of the appended claims. 

Having thus described our invention, what we claim as 
new and desire to secure by Letters Patent is as follows: 

1. A system for transferring data between one or more 
computer systems, comprising in combination: 

a portable, hand-held, data storage unit, including a 
microprocessor, a solid-state memory means opera - 
tively coupled to said microprocessor, a communica- 
tions port operatively connected to said 
microprocessor, arid means including said micropro- 
cessor for generating graphical user interface control 
signals; 

a computer system with a graphical user interface appli- 
cation program responsive to said graphical user inter- 
face control signals; 

said computer system transmitting data to said micropro- 
cessor via said communication port in response to said 
graphical user interface control signals; 

said microprocessor storing said data in said solid-state 
storage means; and 

said microprocessor transmitting said data stored in said 
memory to said computer system. 

2. A portable hand-held data storage unit as in claim 1 
wherein said communications port includes a wireless trans- 
ceiver. 

3. A portable hand-held data storage unit as in claim 1 
further including a battery for powering said unit. 

4. A portable hand-held data storage unit as in claim 3 
wherein said microprocessor transfers between a normal 
operating mode in response to operational inputs and a low 
power operating mode in the absence of said operational 
inputs. 

5. A portable hand-held data storage unit as in claim 1 
wherein said manually operable, graphical user interface 
control signal generating means includes a rotatable member 
and counter means to store incremental rotation of said 
member. 

6. A portable hand-held data storage unit as in claim 5 
wherein said microprocessor transfers between a normal 
operating mode in response to operational inputs and a low 
power operating mode in the absence of said operational 
inputs. 
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Improved methods and arrangements are provided for 
actively monitoring and/or controlling calls and related 
features in a communications system, such as, for example, 
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(GUI) is provided to visually represent the telephony 
resources, features, services, and users prior to, during, and 
after a call. An operator can interface with the computer 
telephony system through the selective activation and/or 
manipulation of graphical and iconic representations of the 
call, the calling party, and called party as provided through 
the GUI. 
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CALL PROGRESS GRAPHICAL USER 
INTERFACE 

BACKGROUND OF THE INVENTION 

1. Technical Field of the Invention 

The present invention relates generally to communication 
systems, and more specifically to methods and arrangements 
that can be employed in computer telephony systems to 
graphically depict incoming and outgoing calls as they 
occur, preferably in a manner that allows a user and/or an 
operator to better monitor and control the calls. 

2. Description of Related Art 

Computer telephony systems are becoming increasingly 
popular because they provide specific services, which in the 
past would have been cost prohibitive if provided by tradi- 
tional telephone systems. Essentially, a computer telephony 
system includes technologies that actively integrate com- 
puters and like devices to function as would a traditional 
telephone system and/or private branch exchange (PBX), 
but only on a smaller scale and/or at a significantly lower 
cost. While a computer telephony system can be a stand 
alone communication system, for example within a home or 
small business environment, it is more likely to also be 
connected to existing telecommunications systems, such as 
a public switched telephone network (PTSN), and/or other 
data networks, such as a local area network (LAN). As such, 
most computer telephony systems are configured to provide 
users with several communication related features. Indeed, 
the inherent flexibility of a programmable computer tele- 
phony system allows for specialized and/or customized 
communication features to be provided, often with only a 
modest attendant increase in cost. 

Of particular interest within computer telephony systems 
is the increased demand from users to integrate new and 
different types of devices and the need to support the 
portability of these devices. The increase in demand for 
mobile cellular radio telephones, personal digital assistants 
(PDAs), pagers, e-mail services, and facsimile services are 
prime examples of the changing requirements that users 
present, even in a small home and/or small business envi- 
ronment. 

The resources available within a computer telephony 
system are uniquely positioned to meet the future needs of 
these service-rich users. To support these and other types of 
needs, however, there is a need to understand how the 
computer telephony system's resources are being utilized. 
This not only assists in determining where problems or 
potential problems might be occurring, but also allows for a 
more complete understanding of the users and their needs 
and how to best address them. Thus, at the simplest level, it 
is important to know how, for example, a call is being placed 
and handled within the operating environment of the com- 
puter telephony system. 

In larger more complicated telephone or PBX environ- 
ments obtaining such information and monitoring/ 
controlling the operation of the overall system can be very 
complicated. As such, these tasks are typically left to auto- 
mated programs, experienced operators and maintenance 
personnel. For example, monitoring and controlling func- 
tions are typically provided through one or more applica- 
tions running on one or more computers within the tele- 
phone or PBX system. Indeed, a significantly large portion 
of the computing resources within such a system can be 
devoted to, or are otherwise involved with, monitoring, 
logging and reporting call activity. 

The information presented by such call activity applica- 
tions tends, however, to be limited in scope due in part to the 
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high level of traffic . Thus, information that may be important 
can become lost or otherwise made substantially difficult to 
extract and analyze, especially on a real time basis. For 
example, information about an incoming or outgoing call 

5 and the resources employed is typically not easily accessible 
to an operator, and the information that is available are 
typically not easily understood by less skilled operators. 
Moreover, seldom would such information have been made 
available to the system's users. 

10 Even in relatively smaller communication environments, 
such as a PBX environment, it is often difficult to track the 
incoming and outgoing calls on a real-time basis or to 
monitor the various features, such as voice mailbox access. 
Indeed, in most typical systems the existence of a telephone 

15 call often require that an inference be made based on the 
reported states of the switching devices making or receiving 
the call. Thus, to an operator, the call itself is, at best, only 
indirectly represented during its lifetime. More detailed 
analysis is typically performed through the subsequent pro- 

20 cessing of collected data within the systems reports and logs. 
For example, data that describes the source and destination 
parties is typically post processed to determine the call's 
duration and associated cost. 
As can be appreciated, in order to support current and 

25 future needs in a smaller scale, feature- rich computer tele- 
phony system, there is a need for improved methods and 
arrangements that allow for dynamic, real-time monitoring 
and analysis of a call or calls. Preferably, the improved 
methods and arrangements will provide increased informa- 

30 tion about the call and present the information to an operator 
and/or users through a user-friendly interface that allows for 
a quick determination of the participants engaged in the call 
and the resources being utilized. Furthermore, there is a need 
for improved methods and arrangements that provide addi- 

35 tional control over the various resources or features within 
the computer telephony system. 

SUMMARY OF THE INVENTION 

40 The present invention provides improved methods and 
arrangements for use in a communications system, such as 
a computer telephony system. In accordance with certain 
aspects of the present invention, a user-friendly, graphical 
user interface (GUI) is provided that allows an operator to 

45 visually monitor and analyze a call. The GUI also provides 
a mechanism for the operator, and in certain cases the users, 
to control various aspects of each call and other telephony 
related features within the computer telephony system. 
In accordance with certain embodiments of the present 

50 invention, therefore, computer instructions within a GUI and 
other related telephony applications are provided in the form 
of a computer readable medium for use in a computer 
telephony system having at least one processor configured to 
respond thereto. The GUI provides a graphical and visual 

55 representation of a call and the resources involved in han- 
dling the call on a display device coupled to the processor. 

For example, in accordance with certain embodiments of 
the present invention a call progress display graphically 
depicts a grouping of all of the participants involved in a 

60 call, together with distinct representations for the different 
states of the resources engaged in the call. By way of further 
example, the call progress display generated by the GUI 
contains cells that represent participants and/or resources 
engaged in the call, and graphical links connected between 

65 these cells. In certain embodiments, for example, iconic 
representations of the various resources are graphically 
displayed within these cells. 
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Thus, by detecting various call activities within the com- FIG. 9 depicts the call progress screen of FIG. 3 showing 

puter telephony system and providing such information to a transfer/conference operation feature, in accordance with 

the GUI, each call can be graphically displayed during its certain embodiments of the present invention; 

progress, duration, and can even be recalled later for addi- FIG. 10 depicts the call progress screen of FIG. 3 showing 

tional analysis. Furthermore, features associated with the s a ca n transfer operation feature in accordance with certain 

call, the resources and/or the users can be invoked or embodiments of the present invention; 

otherwise controlled through one or more input devices and pIG. 11 depicts the call progress screen of FIG. 3 showing 

the GUI, a i^jj 0 p era tion feature, in accordance with certain 

The information that is displayed through the GUI can embodiments of the present invention; 

vary, depending upon the computer telephony system io FIGtl2d ictsthecall essscreenofFIG<3showing 

resources, and the operational and user needs By way of a yoice mdl bQX informalkm feature? in accordance wilh 

example, the GUI can graphically display additional iden- ceftain embodiments of the t invention; 

tifyuig information about the participants engaged in the . mr - 

call, the device used to originate the call, the device which u FIGS U «7 b d f epict the cal1 f 0gress Scree ° ° f FIG P 3 

first received the call, the types and states of devices and 15 showin S a list of C0Dtac J s > and an associated menu for 

automated features subsequently participating in the call, selectm S f rUn £ °P U ° ns for u u se Wlth ^e hst of contacts, 

and other telephony operations/services associated with respectively, in accordance with certain embodiments of the 

each of the devices participating in the call. P rcscrjt invention; 

In accordance with still other aspects of the present FIG Ua de P icts thc cal1 P ro S rcss screen of mG - 3 

invention, the GUI is further configured to provide the 20 showing an incoming call and a detail selection mechanism, 

operator and/or users with manual or automated control in accordance with certain embodiments of the present 

capabilities to actively direct the call's flow and add or invention; and 

delete call participants to the call. FIG. 14b depicts the call progress screen of FIG. 3 

In accordance with certain embodiments of the present showing additional details for a caU, in accordance with 

invention, the GUI is installed within a personal computer 25 certain embodiments of the present invention. 

(PC) operating under a Windows 98 or like environment. DETAILED DESCRIPTION OF THE 

The PC is coupled to a telephony base station that provides PRESENTLY PREFERRED EMBODIMENTS 
telephony functions to one or more devices and provides 

connections to external networks. The present invention will now be described more fully 

BRIEF DESCRIPTION OF THE DRAWINGS " 

A more complete understanding of the methods and This invention may, however, be embodied in many different 
arrangements in accordance with certain embodiments of the forms and should not be construed as limited to the embodi- 
present invention may be had by reference to the following mcn ts set forth herein; rather, these embodiments are pro- 
detailed description when taken in conjunction with the 35 v ided so that this disclosure will be thorough and complete, 
accompanying drawings wherein: an d will fully convey the scope of the invention to those 

FIG. 1 is a block diagram depicting a telephony arrange- skilled in the art. 

ment having a wireless hub arrangement that is arranged to piG. 1 is a block diagram depicting a computer telephony 

provide telephony functions, in accordance with certain system 100 that is arranged to provide voice and/or data 

embodiments of the present invention; 4 communications to a plurality of local users. In order to 

FIG. 2 is a block diagram depicting an exemplary wireless accomplish this task, computer telephony system 100 

hub arrangement, as in FIG. 1, having a computer system includes a hub 102 that is arranged to provide telephony 

configured to run a graphical user interface (GUI) functions, e.g., wireless communications, to a plurality of 

application, a base station device, and at least one user users through devices I04a-n. Although not shown, hub 102 

device, in accordance with certain embodiments of the can also be arranged to support wired communications to 

present invention; other devices. 

FIG. 3 depicts a graphical representation of an exemplary As depicted, hub 102 is connected to at least one external 

call progress screen as displayed on the display device in the network 106 through one or more wire or fiber lines 108. In 

computer system in FIG. 2 in response to the GUI 5Q otner embodiments, lines 108 can also include wireless 

application, in accordance with certain embodiments of the connections. In this manner, computer telephony system 100 

present invention; is configured to provide telephony services through one or 

FIG. 4 depicts the call progress screen of FIG. 3 showing more telecommunications networks. Hub 102, therefore, 

an incoming call, in accordance with certain embodiments provides the signal interfacing, switching, monitoring, and 

of the present invention; 55 controlling functions as required to support the various 

FIG. 5 depicts the call progress screen of FIG. 3 showing telephony services, features and operations, 

a connected incoming call, in accordance with certain By way of example, in accordance with certain embodi- 

embodiments of the present invention; ments of the present invention, external network 106 can be 

FIG. 6 depicts the call progress screen of FIG. 3 showing any type of communications network that is arranged to 

a call directed to a voice mail service, in accordance with 60 provide communications with remote users and/or devices, 

certain embodiments of the present invention; such as, a public switched telephone network (PTSN). 

FIG. 7 depicts the call progress screen of FIG. 3 showing Additionally, external network 106 in certain further 

a call control from an operator's console feature, in accor- embodiments includes or otherwise provides an interface to 

dance with certain embodiments of the present invention; other external network resources such as an intranet and/or 

FIGS. 8a-i!> sequentially depict the call progress screen of 65 me Internet. 

FIG. 3 showing a consult operation feature, in accordance Devices 104a-n can include any type of communication 

with certain embodiments of the present invention; device that is configured for accessing a computer telephony 
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system. By way of example, device 104a can be a wireless 
telephone or pager type of device, device 1046 can be a 
modem-configured computing device such as a portable 
computer or personal digital assistant type of device. 
Devices 104a-/z are typically configured to transmit and 
receive (i.e., exchange) information in the form of either 
analog or digital data through hub 104, lines 108 and the 
various resources provided by external network 106. 

FIG. 2 is a block diagram depicting an exemplary hub 102 
that is based primarily on a computer architecture, such as, 
for example, that found in a contemporary personal com- 
puter (PC) or like computer system. Indeed, in accordance 
with certain preferred embodiments of the present invention, 
hub 102 includes a conventional PC that is connected to a 
base station 216 and configured to run one or more tele- 
phony applications, including a GUI application. 

Referring to the exemplary embodiment depicted in FIG. 
2, within hub 102 there is at least one processor 200 that is 
connected to a primary memory 202 through a first bus 204. 
Processor 200, for example, can be a microprocessor, such 
as a Pentium II microprocessor available from Intel Corpo- 
ration of Santa Clara, Calif. Processor 200 is configured to 
access primary memory 202 through first bus 204. Primary 
memory 202 includes random access memory (RAM), such 
as, dynamic random access memory (DRAM), which is 
configured to store data associated with at least one appli- 
cation 218 that runs in processor 200. 

As shown in FIG. 2, first bus 204 is further interfaced to 
a second bus 208, through a bus interface (I/F) 206. By way 
of example, second bus 208 can be a Universal Serial Bus 
(USB), a Peripheral Component Interconnect (PCI) bus, an 
Industry Standard Architecture(ISA) bus, or other similar 
bus. 

A plurality of devices can be connected to second bus 208. 
For example, as depicted, a secondary memory 210 can be 
connected to second bus 208 to provide additional data 
storage. Secondary memory 210 can include, for example, 
additional RAM, DRAM, static random access memory 
(SRAM) (e.g., flash memory), a disk or tape drive and 
associated magnetic or optomagnetic storage medium, an 
optical storage drive and optical storage medium, or other 
like storage device. 

At least one input device 212 is also connected to second 
bus 208 and configured to accept inputs from an operator. 
Input device 212 can include, for example, a keyboard 
device, a mouse device, a trackball device, a pen device, a 
pointing device, a touch sensitive input device, a micro- 
phone device, or other like input device. The inputs from 
input device 212 are then provided to processor 200, appli- 
cation 218, or any of the other applicable connected devices 
in FIGS. 1 and 2. 

At least one output device 214 is also connected to second 
bus 208. Output device 214 is configured to generate an 
output suitable for use by a user (with or without additional 
devices) in response to one or more signals from processor 
200. By way of example, output device 214 can include a 
cathode-ray tube (CRT) generated display, flat panel display, 
a printer, an audio monitor, or other like devices. In accor- 
dance with certain preferred embodiments of the present 
invention, output device 214 includes a display device such 
as a CRT or flat panel display. 

Hub 102 also includes a base station 216 that is configured 
to support telephony operations within computer telephony 
system 100. As shown, base station 216 is connected to 
second bus 208. Base station 216 includes, for example, a 
switch matrix and associated processing and/or interface 
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circuitry (not shown). In a wireless hub arrangement 100, 
such as that depicted in FIG, 1, base station 216 also 
includes transceiver circuitry that supports the wireless 
communications to/from devices 104a~n. Base station 216 

5 also provides an interface to lines 108. 

Base station 216 is configured to exchange information 
and to respond to one or more commands from application 
218 to selectively control the switch matrix as required to 
support various telephony operations. To accomplish this, 

10 base station 216 is configured to provide status information 
about the telephony operations, e.g., information about a 
call, and status information about or from the various 
devices 104a-n. 
An optional network interface device 218 is also con- 

15 nected to second bus 208 to provide additional non- 
telephony communications between processor 200, for 
example, a local area network (LAN) (not shown). 
Although second bus 208 is depicted as connecting sev- 

2Q eral different devices to first bus 204 and processor 200, it 
is to be understood that this is only an exemplary 
configuration, and that certain additional embodiments in 
accordance with the present invention use a plurality of 
buses, direct interfaces, and/or shared interfaces between the 

25 various devices. 

Further, it is to be understood that additional devices can 
be connected to or otherwise provided in hub 102 as needed 
to support wired or wireless communications and/or other 
networking capabilities. 

30 Reference will now be made to FIGS. 3-14, each of which 
depicts a screen shot of an exemplary call progress display 
300 as generated on output device 214 in response to at least 
graphical user interface (GUI) application 218 running on 
processor 200, in accordance with certain exemplary 

35 embodiments of the present invention. 

Call progress display 300 is essentially a graphical rep- 
resentation of calls in progress in computer telephony sys- 
tem 100. As depicted in FIG. 3, call progress display 300 
includes a miniature call panels area 302, a resource panel 

40 304, and a main call view area 306. 

Within the miniature call panels area 302, there are a 
plurality of miniature panels 303 that depict summary call 
activity within computer telephony system 100. Each min- 
iature panel 303 consists of two cells 303a and 3036. The 

45 first cell 303a represents the call initiator and the second cell 
303fc represents the call receiver. 

As depicted in FIG. 4, for example, when a call appears 
in computer telephony system 100, either because of a user 

5Q initiating a call or because of an external party initiating the 
call, the call is displayed in the miniature panel 303. Each of 
the cells 303a-£> contains an icon and a caption identifying 
the call initiator and the call receiver, and the type of these 
participants (e,g v the type of device or feature). 

55 As additional calls appear in the system, they each take up 
an empty miniature panel 303. When a call ends, the 
miniature panel 303 displaying the call is freed up. Each of 
the miniature panels 303 is updated to reflect the entry and 
exit of call participants into and from the call. In this manner, 

60 at any given time the miniature call panels 303 reflect the 
two active participants in a call. 

The main call view area 306 displays the call participants. 
Each participant has an iconic representation 307 to indicate 
the type of device \04a-n (e.g., handset, mailbox, IVR 

65 agent, external caller, etc) and the current state (e.g., 
ringing, connected, on-hold, etc.) of the call participant. For 
example, as depicted in FIG. 4, an incoming call over line 
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number 1 is shown as ringing the called user's handset as to the call being displayed in the main call view area 306. 

depicted by icon 3076. The call detail window 317 is popped open by clicking on 

As the state of the call participant changes, the icon a button 319 in the lower right corner of the main call view 

representing the participant changes. Thus, as depicted in area 306, as shown, for example, in FIGS. 14a-/?. Upon 

FIG. 5, the icon 3076 represents that the called user has s clicking this button, call detail window 317 is opened, as 

changed state (e.g., vertical orientation versus tilted depicted, for example, in FIG. 146. This window contains a 

orientation), thereby identifying that the incoming call has chronological or similar listing of call events that have 

been answered. In accordance, certain embodiments of the occurred with regard to the call. Each event entry 321 in this 

present invention, icons, such as icons 307a, 3076 and/or window describes what happened in the system in the 

3076 can also be animated to indicate a state, which requires 10 context of the call By reading through this chronology of 

user or operator attention (e.g., blinking, jiggling, color eveQts> the operator can build a mental picture of the call 

changes, enlarging, etc). flow ^ featurc can be usefu] ^ explaining such mings as 

As participants enter and exit from a call, the iconic who initiated the call, how the call was routed, and how each 

representations are either added or removed from the ca ind i vidua i participant interacted with the call or directed the 

progress display 300. The relative positions or the call flow of the call 

participants in the main call area 306, for example, within ' 

cells arranged in a pattern such as a semi-circle, illustrate the Several exemplary call progress display 300 related tele- 
order in which the participants entered the call (i.e., see FIG. P hon y Matures, such as those described above and others, 

will now be discussed with reference to the exemplary 

An additional feature of the main call area 306 is the screen shots of FIGS 3-14 

ability for an operator to invoke call control commands from 20 FIG. 3 depicts a default call progress screen in which the 

the device (e.g., 104a-«) belonging to a call participant. For resource panel 304 is m the handset mode and displays all 

example, as the operator moves a cursor over the icon handsets (i.e., devices 104a-n) that are currently subscribed 

representing a call participant, a menu of commands is to the computer telephony system 100. 

displayed. The commands in such a menu can include, for In FIG. 4, an incoming call on Line 1 is depicted as it is 

example, various telephony commands (e.g., Transfer, routed to a subscribed handset in the computer telephony 

Redirect, Conference, etc.,) which are valid for the current system. Next, as shown in FIG. 5, the incoming call on Line 

state of that participant. 1 is depicted as having been answered by a person with 

When a command is selected from the menu, for example, access to a subscribed handset in the computer telephony 

by clicking the appropriate menu item, the command is 3Q system. Alternatively, as depicted in FIG. 6, if the incoming 

immediately invoked, provided no further input is required. call to the subscribed handset is not answered then, the 

Otherwise, the operator is prompted through visual and/or incoming call on Line 1 is depicted as having been routed to 

audio cues, for example, to select a call destination appro- the voice mail box 323 for the subscribed handset. Here, the 

priate for a given command. Once the operator has made a operator can listen in on the voice mail message and/or 

valid selection the command is invoked. 35 redirect the call as needed. 

As depicted in FIG. 5, for example, resource panel 304 on As depicted in FIG. 7, the call progress screen and 

the far left-hand side of display 300 includes a plurality of associated application 218 allow the operator to control calls 

tabs 308. The first is a handsets tab 308a that, when selected using the GUI. Here, the operator can consult, transfer or 

by the operator, displays a list of all users in the system with trash the incoming call, as described below. Additionally, in 

a handset device. The second is a mailboxes tab 3086 that, 40 accordance with certain preferred embodiments of the 

when selected by the operator, displays a list of all users with present invention, the application 218 includes the capability 

a voice mailbox. The third is a contacts tab 308c, that when to allow users to control certain features of incoming calls 

selected by the operator, displays a list of contacts entered in via the voice commands and/or by using a handset keypad, 

the address book of the system. The computer telephony system 100, described herein 

The operator can click on the appropriate tab 308 to look 45 provides several features. For example, using the GUI 
at a particular list. For example, as depicted in FIG. 5, when associated with call progress screen 300, an operator can 
handsets tab 308a is selected, a list of users 309 with either route a call to another subscribed handset for a 
handsets is displayed in resource panel 304. In FIG, 12, for consult/conference call, transfer the call to another sub- 
example, when mailboxes tab 3086 is selected, a list of users scribed handset, or send the call to a recorded message (e.g., 
with mailboxes 311 is displayed in resource panel 304. 50 after-hours, trashed, etc.). 

Finally, referring to FIG. 13a, when contacts tab 308c is These and other similar features are also provided to users 

selected, a list of contacts 313 is displayed in resource panel of handsets through voice commands and/or the handset's 

304. List of contacts 313 can include information, such as, keypad. By way of example, the call progress screen 300 in 

for example, the name, company name and the default phone FIGS. 8a-6 illustrate that the user has selected a consult 

number assigned to each contact. From the list of contacts 55 option and is contacting another subscribed handset to either 

313 the user can also selectively access pop-open, pull- consult with and/or to include in a conference call. During 

down, or like types of menus (not shown) that include all the this process the caller on Line 1 is placed on hold as noted 

dialable numbers assigned to a contact. by a flashing of the Line 1 icon 325, as graphically illustrated 

When prompted to choose a call destination, the operator in FIG. Sa. As such, as depicted in FIG. 86, a subscribed 

can either click the icon representing the call destination of 60 handset has answered the call and now the call can be either 

choice or in the case of a contact, select one of many transferred to that handset or included in a conference call, 

possible numbers assigned to a contact. The contacts can In this configuration icon 325 preferably does not flash, 

also be sorted by first name, last name, and company name Next, as depicted in FIG. 9, once a subscribed handset 329 

or telephone number, for example, as depicted in FIG. 136 is contacted via the consult option and the user of the 

using menu 315. 65 subscribed handset 329 answers the call, then either the 

Another feature that is provided is a call detail window consulting user 327 or the operator can select to transfer the 

317, which contains a chronology of events that are related call to the subscribed handset 329 that was consulted, or 
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alternatively to include the subscribed handset 329 in a 
conference call. 

FIG. 10 depicts the graphical depiction of a blind transfer 
operation, wherein a call that is answered by the designated 
subscribed handset 331 can be transferred to another sub- 
scribed handset (not shown) without voice contact between 
the two handset users. 

Similarly, as depicted in FIG. 11, a trash call can be 
handled through the GUI or from handset using a trash call 
option that transfers a call to a pre-recorded message. For 
example, a trash call message can inform the caller that his 
call is not accepted by the recipient 333. 

As depicted in FIG. 12, the mailboxes tab 308ft has been 
selected and a list of users with a voice mailbox 311 is 
displayed in resource panel 304. Each of the user mailboxes 
311 selectable through the GUI by clicking on the appro- 
priate mailbox icon (e.g. 311a, 311&, etc.). 

In FIG. 13a, the contacts tab 308c has been selected and 
a list of contacts 313 is displayed in resource panel 304. The 
list of contacts 313 can be selected and parsed by the 
operator using the GUI or alternatively by the users via voice 
commands and/or handset keypad commands. As depicted 
in FIG. 136, for example, the list of contacts 313 can be 
sorted by either First Name, Last Name, Company Name or 
Telephone Number. 

Referring to FIG. 14a, within the main call view area 306 
there is a call detail button 319 that can be selected by the 
operator, for example, to view the call activities as they are 
happening in the system, or to view call history data. When 
the call detail button is selected, a call detail area 317 opens 
up within call progress display 300. Within call detail area 
317 are listed various details of the call's progress/history 
and related activities. 

As described above and depicted in the various exemplary 
embodiments of FIGS. 1-14, computer telephony system 
100 includes a GUI application 218 that allows for advanced 
features typically associated with a PBX, but at a more 
reasonable cost and with an improved graphical depiction of 
the operation of the computer telephony system's resources 
and features. Using such a GUI, operator control and moni- 
tor functions are provided through a visually active display 
that can be easily understood by the operators. This allows 
operators to better manage incoming and outgoing calls, and 
to optimize or otherwise adjust the telephony services that 
are provided to the various users. As new services are added, 
iconic representations can be incorporated into the object 
oriented display screens and cells. Further, new lists of these 
and other services can be added to the resource panel 304. 

As will be recognized by those skilled in the art, the 
innovative concepts described in the present application can 
be modified and varied over a wide range of applications. 
For example, the GUI interface and/or various aspects of the 
exemplary embodiments can be adapted for use in other 
communication systems, including larger systems, such as, 
PBXs, and portions of telephone system. Accordingly, the 
scope of patented subject matter should not be limited to any 
of the specific exemplary teachings discussed. 

What is claimed is: 

1. A graphical user interface (GUI) for within a commu- 
nications system, the graphical user interface comprising: 

at least one display device: 

a first iconic representation of a calling party; 

a second iconic representation of a called party, the 
second iconic representation being configured to rep- 
resent at least two different states associated with a call 
status; 
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means for displaying the first and second iconic repre- 
sentations on the display device; and 

an indicia connecting the first iconic representation with 
the second iconic representation on the display device, 
s said means for displaying the first and second iconic 
representations on the display device being further 
configured to display a plurality of visually separated 
areas on the display device, including at least a first 
area capable of displaying the first and second iconic 
30 representations and a second area comprising a 
resource panel, said resource panel including a plurality 
of selectable tabs. 

2. The graphical user interface (GUI) as recited in claim 
1, wherein the first iconic representation of a calling party 
further includes an identifier of the calling party. 

3. The graphical user interface (GUI) as recited in claim 
1, wherein the second iconic representation of the called 
party further includes an identifier of the called party. 

4. The graphical user interface (GUI) as recited in claim 
1, further comprising a graphical representation visually 
connecting the first iconic representation with the second 
iconic representation on the display device. 

5. The graphical user interface (GUI) as recited in claim 
1, wherein at least one of the plurality of selectable tabs, 
when selected causes the means for displaying the first and 

25 second iconic representations on the display device to fur- 
ther display at least one list on the display device in the 
second area, 

6. The graphical user interface (GUI) as recited in claim 
5, wherein the at least one list is selected from the group 
consisting of a list of handset users, a list of voice mailbox 
users, and a list of contacts. 

7. The graphical user interface (GUI) as recited in claim 
1, further comprising a means for inputting user selections 
that cause the means for displaying the first and second 
iconic representations on the display device to change at 
least a portion of the representations in the display device. 

8. The graphical user interface (GUI) as recited in claim 
1, further comprising a call detail area for displaying a list 
of events related to a call. 

4 9. The graphical user interface (GUI) as recited in claim 
1, wherein iconic representations of additional call partici- 
pants are displayed using a chronologic representation. 

10. A method for displaying call progress information on 
an operator display screen within a communications system, 
the method comprising: 

displaying a first iconic representation of a calling party; 
displaying a second iconic representation of a called party, 

the second iconic representation being configured to 
50 represent at least two different states associated with a 

call status; 

connecting the first iconic representation and the second 
iconic representation with an indicia on the display 
screen; 

ss displaying the first and second iconic representations in a 

first area visually separated from at least a second area 

on the display device; and 
display a resource panel within the second area, said step 

of displaying the resource panel further comprising, 
60 displaying at least one selectable tab within the 

resource panel. 

11. The method as recited in claim 10, further comprising 
displaying an identifier of the calling party associated with 
the first iconic representation of the calling party. 

65 12. The method as recited in claim 10, further comprising 
displaying an identifier of the called party associated with 
the second iconic representation of the called party. 
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13. The method as recited in claim 10, further comprising 
displaying a graphical representation that visually connects 
the first iconic representation with the second iconic repre- 
sentation. 

14. The method as recited in claim 10, further comprising s 
displaying at least one list on the display device in the 
second area when the tab is activated. 

15. The method as recited in claim 14, wherein the at least 
one list is selected from the group consisting of a list of 
handset users, a list of voice mailbox users, and a list of 10 
contacts. 

16. The method as recited in claim 10, further comprising 
accepting user selections and in response changing at least 
a portion of the representations on the display device. 

17. The method as recited in claim 10, further comprising 15 
the step of displaying a list of events related to a call. 

18. The method as recited in claim 10, wherein iconic 
representations of additional call participants are displayed 
using a chronologic representation. 

19. A computer readable medium comprising at least one 20 
computer instruction that causes at least one processor 
within a communications system to perform operations 
including: 

displaying a first iconic representation of a calling party 
on a display device coupled to the processor; 25 

displaying a second iconic representation of a called party 
on a display device coupled to the processor, the second 
iconic representation being configured to represent at 
least two different states associated with a call status; 

30 

connecting the first iconic representation and the second 
iconic representation with an indicia on the display 
device; 

displaying the first and second iconic representations in a 
first area that is visually separated from at least a 35 
second area on the display device; 
displaying a resource panel within the second area; and 
displaying at least one selectable tab within the resource 
panel. 

20. The computer readable medium as recited in claim 19, 40 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 
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displaying an identifier of the calling party associated 
with the first iconic representation of the calling party, 

21. The computer readable medium as recited in claim 19, 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 

displaying an identifier of the called party associated with 
the second iconic representation of the called party. 

22. The computer readable medium as recited in claim 19, 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 

displaying a graphical representation that visually con- 
nects the first iconic representation with the second 
iconic representation. 

23. The computer readable medium as recited in claim 19, 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 

displaying at least one list on the display device in the 
second area when the tab is activated. 

24. The computer readable medium as recited in claim 23, 
wherein the at least one list is selected from a group 
consisting of a list of handset users, a list of voice mailbox 
users, and a list of contacts. 

25. The computer readable medium as recited in claim 19, 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 

accepting user selections; and 

in response, causing at least one of the first and second 
iconic representations to change. 

26. The computer readable medium as recited in claim 19, 
further comprising at least one computer instruction that 
causes at least one processor within the communications 
system to perform operations including: 

displaying a list of events related to a call in a call detail 
area. 

27. The computer readable medium as recited in claim 19, 
wherein iconic representations of additional call participants 
are displayed using a chronologic representation. 

***** 
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[57] ABSTRACT 

A docking system for establishing secure wireless connec- 
tion between computer devices is presented. The technique 
assumes that at least one of the computer devices comprises 
a portable device. Means are provided for automatically 
establishing wireless connection between the portable 
device and the second device when the portable device is 
brought within the docking port (or docking area) of the 
second device. This automatic establishing of wireless con- 
nection includes communicating an address identifier 
between the portable device and the second device once the 
portable device is "docked." If desired, an encryption key 
can also be exchanged with the address identifier to allow for 
encryption of information communicated between the 
devices. After docking, the first device can be removed from 
the docking area without affecting the wireless connection 
between the first device and the second device. 

30 Claims, 7 Drawing Sheets 
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DOCKING SYSTEM FOR ESTABLISHING 
SECURE WIRELESS CONNECTION 
BETWEEN COMPUTER DEVICES 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application comprises a continuation-in-part of prior 
filed pending U.S. patent application Ser. No. 08/296,219, 
Aug. 25, 1994, entitled "Data Mouse/' which is hereby 
incorporated herein in its entirety. 

This application is being filed on the same day as related 
applications, PO9-97-033, PO9-97-034 and PO9-97-035. 

TECHNICAL FIELD 

The present invention relates in general to wireless data 
communication between different computer devices, and in 
particular, to a docking system and method for automatically 
establishing secure wireless connection between a portable 
computing device and another intelligent device. 

BACKGROUND ART 

In the existing art, there are a variety of devices and 
networks to move data from one data processing system 
(e.g., a first personal computer system) to another data 
processing system (e.g., a second personal computer 
system). These techniques include diskettes (e.g., magnetic 
and optical), local area hardwired networks, various wireless 
transmission networks, and semiconductor memory cards. 

Of particular relevance to the present invention is the use 
of a wireless methodology for transferring data from a 
portable data storage device to a data processing system. For 
example, in the above-incorporated U.S. Patent Application 
entitled "Data Mouse," a portable, hand -held device for 
transferring data to and from a data processing system via a 
graphical user interface is presented. A wireless communi- 
cation link provides two-way communication between the 
computer and the hand-held data storage unit. The comput- 
er's graphical user interface is expanded to provide an icon 
representing a process that transfers data to or from the 
hand-held data storage unit in response to a pointer position 
controlled by the hand-held data storage unit. Data com- 
pression and/or encryption may be executed by the computer 
in response to another icon, or a pop-up menu, controlled by 
the hand-held unit prior to data transfer and storage in the 
unit. 

A potential problem with use of such wireless communi- 
cation methodology occurs where the data mouse is 
employed in relatively close proximity to a plurality of 
intelligent devices, any one of which the mouse may com- 
municate with via wireless modality. In such an 
environment, there is a possibility for unauthorized inter- 
ception of interdevice information being transmitted, as well 
as transfer of data information to an unintended device. 
Thus, in an environment with a dense assemblage of 
devices, any one of which can communicate with the data 
mouse or other portable device within range of the wireless 
communications modality, a method is needed to specify 
which intelligent device is to communicate with which 
portable device and conversely, which portable device is to 
receive requests and/or information issued by a member of 
the assemblage of devices. 

Inter-device security and communications selectivity in 
configurations of devices which are wired together has been 
solved many times in the art. In addition, a variety of similar 
methods exist for a multiplicity of devices in a wireless static 
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configuration. Typically, in such an environment a user must 
explicitly specify the device address (for a Local Area 
Network (LAN), the device address is fixed and implicit in 
the firmware of the LAN card). Communications in a wired 

5 configuration of computers is reasonably secure from casual 
interception and easily routed. In a wireless configuration of 
devices, specific device addresses must be assigned. 
Depending on whether there is a need for security, the 
information carried on the wireless medium may be 

10 encrypted. The user must explicitly enter the encryption key 
into each device. This requirement of entering the encryp- 
tion key information and the communications address is user 
unfriendly and time consuming; and requires increased 
expense for an entry method, such as buttons, switches, etc., 

15 which increases the cost of the portable device. 

Thus, there exists a need in the art for a technique which 
is user friendly and inexpensive to implement for readily 
establishing a wireless data connection between a portable 
device and a selected one of a plurality of intelligent devices. 

20 

DISCLOSURE OF INVENTION 

Briefly summarized, the invention comprises in one 
aspect a docking system for establishing secure wireless 

25 connection between a first device and a second device, the 
first device comprising a portable device. The docking 
system includes a first wireless communication means com- 
prising part of the first device and a second wireless com- 
munication means comprising part of the second device. 

30 Together, the first and second wireless communication 
means provide for wireless communication between the first 
device and the second device. The docking system further 
comprises means for automatically establishing secure wire- 
less connection between the first device and the second 

35 device when the first device is brought within a predefined 
docking area of the second device. This means for automati- 
cally establishing secure wireless connection between the 
first device and second device includes means for automati- 
cally exchanging an address identifier between the first and 

40 second devices when the first device is brought within with 
the predefined docking area of the second device. With the 
exchange of the address identifier, the portable device can be 
removed from the docking area without terminating the 
wireless connection between the first device and the second 

45 device. 

In another aspect, the invention comprises a docking 
system for establishing wireless connection between a first 
device and a second device, the first device again comprising 
a portable device. In this system, a docking port is associated 

50 with the second device. The docking port, which is sized to 
at least partially engageably receive the first device, is in 
communication with the second device. A first communica- 
tion means comprises part of the first device and a second 
communication means comprises part of the second device. 

55 These communication means provide for wireless commu- 
nication between the first device and the second device. A 
means for automatically establishing wireless connection 
between the first device and the second device is also 
provided which includes means for automatically commu- 

60 nicating an address identifier between the first device and the 
second device when the first device is brought within the 
docking port. After removal of the first device from the 
docking port, the first and second devices maintain the 
wireless connection using the address identifier for commu- 

65 nication of information therebetween. 

In a further aspect, a method for establishing wireless 
connection between a first device and a second device is 
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provided. Again, at least the first device comprises a portable 
device. The second device is further assumed to have a 
docking area defined in association therewith. The method 
includes: docking the first device within the docking area; 
and automatically establishing wireless connection between 
the first device and the second device in response to docking 
of the first device within the docking area. This automatic 
establishing of wireless connection includes automatically 
communicating an address identifier between the first device 
and the second device when the first device is docked within 
the docking area. After removal of the first device from the 
docking area, the first device and the second device maintain 
their wireless connection using the communicated address 
identifier for the communication of information therebe- 
tween. 

To restate, presented herein is a docking system and 
method for automatically establishing secure wireless com- 
munication between a portable device and a selected intel- 
ligent device of a plurality of intelligent devices. A signifi- 
cant goal of the approach presented is ease of use. 
Specifically, this invention allows establishment of wireless 
data communications between devices in a manner that is 
user friendly and inexpensive to implement. An address 
identifier, and possibly an encryption key, is automatically 
exchanged between a portable device and a selected intel- 
ligent device upon docking of the portable device at a 
predefined docking area associated with the selected intel- 
ligent device. Through the use of limited range wireless 
communications, this information can be exchanged without 
also revealing the information to other intelligent devices 
not in sufficiently close proximity. In maximally secure 
situations, docking can be via a temporary wired connection 
for the exchange of the identifier address and encryption key. 

The docking approach presented can be applied to various 
portable devices, including a data mouse and personal 
digital assistants. Again, the disclosed solution to establish- 
ing wireless connection largely relieves the user of any key 
entry requirements, as well as relieving the user of a need to 
assign addresses. In addition, by suitably setting up the 
possible address configurations, the probability of errant 
communications between a portable device and the plurality 
of intelligent devices in proximity thereto can be rendered 
negligible. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The subject matter which is regarded as the present 
invention is particularly pointed out and distinctly claimed 
in the concluding portion of the specification. The invention, 
however, both as to organization and methods of practice, 
together with further objects and advantages thereof, may 
best be understood by reference to the following detailed 
description taken in conjunction with the accompanying 
drawings in which: 

FIG. 1 is a schematic of one embodiment of a portable 
data device wirelessly linked to a computer system for 
transfer of data therebetween; 

FIG. 2 depicts an environment wherein a plurality of 
intelligent devices are disposed in close proximity to each 
other, any one of which the portable data device of FIG. 1 
may communicate with via wireless modality; 

FIGS. 3a and 3b are a plan view and a side elevational 
view, respectively, of a portable data device for use in 
accordance with the present invention; 

FIG. 4 is a schematic of one embodiment of wireless 
communication circuitry within the portable data device of 
FIGS. 3a and 36; 
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FIGS, 5a and Sb depict a computer display having a 
docking port in accordance with one embodiment of the 
present invention; 

FIG. 6 is an enlarged view of the portable data device of 
FIGS. 3a and 3b docked within the docking port of FIGS. 5a 
and 5b; 

FIG. 7 is a flowchart of one embodiment for establishing 
communication connection between a portable device and 
another device in accordance with the present invention; 

FIG. 8 is a flowchart of one embodiment for establishing 
encryption on the communication connection between the 
portable data device and the intelligent device to which the 
portable device is docked; 

FIGS. 9a and 9b are a plan and elevational view, 
respectively, of an alternate embodiment of a portable data 
device for use in accordance with the present invention; and 

FIG. 10 is a schematic of an alternate docking approach 
for establishing communication connection between the 
portable data device and a computer system in accordance 
with the present invention. 

BEST MODE FOR CARRYING OUT THE 
INVENTION 

Generally stated, the present invention comprises a con- 
venient technique for ensuring secure wireless communica- 
tions between a portable device and a selected device of a 
plurality of intelligent devices in a dense computing envi- 
ronment. The selected intelligent device could be a station- 
ary device or a mobile computing device. Also, communi- 
cation does not necessarily need to occur in a one-to-one 
relationship. A central concept of the present invention is the 
idea of initially "docking" one computing device (for 
example, the portable device) with another computing 
device to which wireless communication is desired. During 
docking, identifying information including an address iden- 
tifier and, if desired, an encryption key, is exchanged. 
Preferably, this exchange occurs automatically once the 
portable device is docked with the selected intelligent 
device. By use of limited range wireless communications, 
encryption and address information can be readily 
exchanged between the two devices using existing 
technology, without also revealing this information to other 
devices (not in sufficiently close proximity). 

Maximum security can be obtained by requiring that 
docking be via temporary wired connection such as connec- 
tor and plug, or some other hard connection, e.g., a shielded 
optical connection. Note that docking in accordance with the 
present invention is a temporary condition. The portable 
device is only docked a sufficient time interval to allow the 
transfer of identifying information between the portable 
device and the computing system so that only that comput- 
ing system will recognize communication signals from the 
portable device after the device is removed from the docking 
port. 

With suitable design of the docking structure and com- 
munication exchange, no additional effort on the part of the 
user is required beyond bringing the mobile computing 
device to within the docking proximity of the other mobile 
or stationary computing device to which communication is 
desired. Various mechanisms can be used to accomplish the 
exchange of information. For example, use of a suitable reed 
relay and magnetic configuration is possible so that any two 
devices can detect proximity to each other. Alternatively, 
low intensity magnetic field induction (coil-to-coil) could be 
employed. 

In the detailed embodiments presented below, the portable 
device is assumed to comprise a data mouse such as 
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described in the above -incorporated application. However, Although the present invention is described herein in con- 

those skilled in the art should recognize that the concepts nection with a mouse, the concepts presented are not limited 

presented herein are equally applicable to other types of to that particular portable structure. Preferably, however, at 

portable data storage or computing devices. For example, least one of the devices to be wirelessly connected com- 

the concepts could apply to docking of a personal digital s prises a portable device, which will facilitate "docking" of 

assistant (PDA), such as the Newton PDA, marketed by the devices. 

Apple Corporation or the Simon PDA marketed by Interna- Device 10 contains standard mouse components such as a 

tional Business Machines Corporation, mouse ball 40 and mouse buttons 16. Not shown in these 

FIG. 1 depicts a portable data storage device 10 wirelessly figures are hardware/software components to implement the 

coupled, e.g., using low power electromagnetic waves 12, to' 10 data mouse concepts of the incorporated application. For 

a computer system 14. System 14 is equipped with graphical further information on such structure and software reference 

user interface software, such as that supported by the IBM the incorporated application. In support of the docking 

OS/2 operating system. Use of electromagnetic waves 14 concept, an infrared (IR) communications means 41 and 

allows greater freedom of placement of device 10 compared supporting electronics 46 are added to wireless mouse 10. 

with a hardwired connection of the devices. Other wireless 15 ^ ^cussed further below m connection 

communication techniques could also be employed. For w j* ^G. 4. Additionally there is an optical means such as 

. . . Z , • ** Ti i-i m u a light emitting diode 48 to visually signal when docking is 

example a wireless optical communication link 13 may be suc * essMly JUnpifehed. Other means of indicating suc- 

used if desired. cessful docking might include tactile sensation means, such 

A standard mouse configuration is shown with two as a vibration device 50 and/or an aural indication means, for 

"clicker" buttons 16 and a mouse ball assembly (not shown). 2 o example, a piezoelectric speaker 52. 

Additional buttons can be supported if necessary, as can M shown in mG 4 electronics 46 includes an infrared 

additional controls. Computer system 14 has a display (t R ) light emitting diode (LED) driver 60, an IR LED 

screen 18 and additional hardware 20 to communicate with receiver 62 and wireless communication support circuitry 

portable device 10. In one embodiment, hardware 18 is 64. Support circuitry 64 incorporates the lowest hardware 

connected via serial cable 19 to computer 14. Thus, hand- 2 5 level of protocol for the communications. One example 

held device 10 is, insofar as being a pointing device, similar would be a universal asynchronous receiver/transmitter 

in operation to a standard serial mouse. For further structural (UART) for each LED driver or receiver. Note that in some 

and operational details of portable device 10 and its com- cases, this circuitry is, or can be incorporated into the 

munication with computer system 14, reference the above- embedded controller of the data mouse, PDA, or other 

incorporated, commonly-assigned pending U.S. application 30 portable computing devise. Optionally included within cir- 

Ser. No. 08/296,219. cuitry 64 is a unique identifier 66 similar in function to the 

As explained briefly above, a significant advantage of the UID of a token ring local area network (LAN) card, 

present invention is the ability to establish secure wireless Specifically, each portable device 10 has a different identifier 

connection between a portable device and a selected com- 66 coded therein. For purposes of integration, note that the 

puting system in a dense computing environment having a 35 actual device identifier may exist in code 68 available to 

plurality of intelligent devices in close proximity to one supporting electronics 46 via a two-way connection 70. The 

another. FIG. 2 depicts one embodiment of such an envi- UID is a universal identifier number which may be unique 

ronment wherein multiple intelligent devices, such as com- for each mouse manufactured. However, this is not a 

puter systems 14', are disposed in close proximity. Each requirement since the ID can be assigned by the computing 

computer system 14' includes docking hardware 30 which 40 element to which the portable device is docked. If assigned 

allows in accordance with the present invention the auto- by the computing element, there is a small but finite chance 

matic establishment of wireless connection between por- in a dense configuration that more than one portable device 

table device 10 and the computer system when device 10 is would have the same identifier, in which case a redocking 

brought within a predefined docking area 32, 32'. Areas 32 would be necessitated. With encryption, even a simple form 

& 32 r are associated with docking hardware 30 of particular 45 of encryption, the chances of casual interception of data 

systems 14* and the docketing areas 32 & 32' do not overlap. would be negligible. Also shown in FIG. 4 is IR commu- 

Once identifying information is exchanged, the wireless nication means 41 disposed at one end of portable device 10. 

communications modality of the portable device can be Another embodiment of the docking concept of the 

employed anywhere within the dense computing environ- present invention is depicted in FIGS. 5a, 5b and 6. FIG. 5a 

ment without information being intercepted or inadvertently 50 shows a computer system 14" having a display means 80 

exchanged with an unintended computer system. Note that with a display screen 81. Computer system 14" might 

the exchange of identifying information is preferably auto- comprise one system of multiple computer systems in a 

matically activated by proximity of the portable device to dense computing environment as described above. Clearly, 

the computing system, i.e., disposition of the device within however, the present invention can also be used apart from 

the docking area of the selected computer system. Thus, no 55 a dense computing environment to initiate wireless connec- 

explicit user action outside of bringing the portable device tion between any two devices equipped with corresponding 

into the docking area is needed to initiate the wireless wireless communication means. In accordance with the 

connection through the exchange of identifying information. invention, display means 80 includes a docking port 83, 

Again, any portable device, such as a track ball or other which is shown in greater detail in FIGS. 5b and 6. In this 

pointing device might alternatively be used in place of the 60 embodiment, docking port 83 comprises a U-shaped struc- 

data mouse discussed herein. ture sized to engage ably accommodate the device 10 at least 

FIGS. 3a and 3fc depict one embodiment of a portable partially therein. Computer screen icon 82 might be 

device 10 in accordance with the present invention. Device employed to show the current status of docking, i.e., whether 

10 is assumed to comprise a data mouse such as described there is currently a portable device docked and/or active for 

in the above-incorporated application. This device 10 has a 65 communicating with the computer system. Further informa- 

built-in means for controlling the pointer on a graphical user tion shown by icon 82 could comprise information described 

interface equipped computing device (see FIGS. 1 and 2). in the above-incorporated application Ser. No. 08/296,219. 
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Icon 82 could also provide additional security during the port. Obviously, this depends upon the position of the 

docking process. For example, a simple key could be docking port and the configuration employed, i.e., whether 

required from the user in order to upload information from a predefined docking area defined in close proximity to the 

the mouse; or a key can be provided to the mouse to further computing system is employed or a physical docking port 

secure information transferred to the mouse as described in 5 structure designed to engageably receive at least a portion of 

the above-incorporated application: Extended icon 82 infor- the portable device is used. 

mation might include time of docking and mouse ID in order FIG- ? depicts one embodiment of a system connection 

that a security trail be available. flowchart in accordance with the present invention. Connec- 

An advantage of having docking port 83 physically tion processing begte^ 

attached to display means 80 is that the display means is io a P ort D able device (100) brought wittun the docking area or 

typically associated with a single computing device, i.e., the ^ ^J^™^?™*™ whether an infrared signal 

device to which communication is desired. If this is not true, » de ff e <* (1»2) and if yes, then whefcer an appropriate 

then the docking port could be attached to the computing identification header is received on hat signal (104). Pro- 

i * ■ 4 i r f i . „ . * cessine holds for a predefined time interval (106) waiting tor 

device itself, or to any other place which may be convenient TJ£? . . • ^ ■ . . . 

and which would indicate to a user an association between 15 recent of the header If this information , is not received 

the docking port and a desired computing element. In this vnthla A ' hat mte ™ l > th ™ a ™ acknowledgement (108) is 

regard, reference the discussion below regarding FIG. 10. P 1 ™** t0 sl S nal dockir^ fa,lure and processmg returns to 

° polling for receipt of an infrared signal (102). As an option, 

As shown in the enlarged view of FIG. 6, contained within a time om dedsion Wock (aot shown) cou]d be added t0 

docking port 83 is an IR communication means 90 which kcc thc doc]dng circuitry into slcep modc (i 2 2) if no 

communicates with IR communication means 41 of the mffared . { ^ received a predetermined time 

portable device when the portable device is physically interval 

engaged within docking port 83 For example, the optical Qnce ^ header fg received ^ cq 

paths match and/or the receptor frequencies are compatible b to communicatioQ 5 initiati a hand . 

for communication between the portable device and the shake F (110 ), and then determines whether the handshake is 

computer system through the communication means of the QK (m) { ^ cq ffl ^ l0 wait 

docking port. The docking port is assumed to be in com- a v defined timc interval (m) and if the handshakc is not 

mumcation with computer system 14 . established as valid within that interval, then the system 

Compared with the handheld data storage device signals docking failure to the user (108). Once handshake is 

described in the above -incorporated application, a portable 30 established, then identification information is exchanged to 

device 10 in accordance with this invention would have establish the connection (116). This information might 

several additional characteristics. Software might be include a device number for the transmit unit header, an 

included to encrypt the serial data stream to the computer encryption key, if desired, and frequency or other informa- 

system and to decrypt the serial data stream from the tion for w i re l e ss communications, for example, a skip 

computer system. Technically, decryption software is not 3S algorithm, i.e., information on frequency hopping or spread 

required provided the encryption key is downloaded during spectrum use. Once the identification information is 

docking of the portable device to the computer system to exchanged, the user is signaled that the docking connection 

receive the data carried by the portable device. That is, the ^ accep ted (118) and the portable device is acknowledged as 

portable device can keep the encrypted data in encrypted activated for wireless communication with the computer 

form and allow the target computer system to which the data 4Q syslem ( 120 ) The portable device is removed from the 

is uploaded to decrypt the data. However, if a mobile docking area or port and the docking circuitry goes into a 

computing device is used rather than a portable data mouse, s]eep mode ( 122 ) until receipt of a next wake up signal 

the mobile computing device may require decryption of data (100). 

in order to make use of that data An encryption method FJG g depicts Qne embodimenl for encryption key 

applied for enhancing security of the wireless commumca- 45 exchange with docking 0 f the portable device. Initially, a 

lions modality is intended only to thwart casual monitoring. dock signa] process s(art (126) {s rece ived. A process start is 

Thus, a simple fast method such as XOR'ing the data stream oflen referrcd to in the art ^ a spawn thread. Spawning a 

with the passed encryption key is acceptable. tfaread {& one way a process stafts irj ceftain systemSj such as 

Preferably, the data mouse or other mobile computing IBM's OS/2 operating system. Process start is followed by 

device provides user feedback that docking is successful via 50 inquiry into whether the portable device is set up to require 

an aural indication, a visual indication, a tactile indication, an encryption key (128). If yes, the encryption key is 

any combination thereof, or any other modality which obtained, e.g. from the user, (130) and the key is transferred 

impinges on the consciousness of the user. The protocol used t0 the portable device (132). In a preferred environment, the 

for both exchange of information during docking and during k e y obtained from the user (130) is randomly generated for 

other times requiring communications would preferably be 55 each docking. By generating the key, the computer system 

the same. increases ease of use of the system. Note that the generate 

One skilled in the art will understand that the computer keys resulting in transmission of plain text would be 

system would contain the following elements in addition to excluded, plain text comprising text that is not encrypted, 

those elements required for support of the handheld data Processing then determines whether the key exchange is 

storage unit described in the above -incorporated application. 60 valid (134). This process is repeated a predetermined num- 

First, docking hardware suitable to interface to the portable ber of times, for example, three times (136) or until a valid 

device hardware or other mobile computing device making key exchange is obtained. If no key is required, then 

use of the docking port. Suitable software and/or firmware, processing jumps from inquiring whether a set up key is 

to support the docking function, i.e., encryption/decryption required (128) to setting the parameters to use the docked 

(if done in software/firmware) and exchange of keys and 65 portable device as a pointer control to the computer system 

device addresses. Also, preferably some sort of visual "tar- (138). Thereafter, the computer system exists docking pro- 

get" indication for a user to assist in locating the docking cessing. In this embodiment, after three unsuccessful 
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attempts to exchange encryption keys (136), the user is 
signalled to redock the portable device to reinitiate the 
docking procedure (140). Processing is then terminated 
(141) pending redocking. 

FIGS. 9a and 9b depict an alternate embodiment of 
portable device 10' wherein an electromagnetic coil 200 is 
employed, for example, for radio wave communication with 
a computer system. The components of portable device 10* 
are the same or analogous to those discussed above in 
connection with device 10 of FIGS. 3a and 3b. Briefly 
explained, device 10' includes toroidal coil 200 for electro- 
magnetic coupling, mouse buttons 202, electronic circuitry 
204 supporting the docking function, reed relay 206 (contact 
portion), a mouse ball 208, and a light emitting diode 210 
visible to a user of portable device 10'. 

FIG. 10 depicts an alternate docking embodiment wherein 
the portable device 10' is physically engaged within a 
docking port 220 separate from an associated computer 
system 222. Docking port 210 is electrically coupled via 
docking hardware 224 to computer system 222. If desired, 
docking hardware 224 can be integrated within the computer 
system 222. One of ordinary skill in the art can implement 
docking hardware 224 based upon the concepts presented 
herein. 

In this embodiment, docking is accomplished by bringing 
mouse 10' in close proximity to docking port 220 so that 
magnet 212 at the docking port closes reed relay 206. The 
closure of relay 206 activates docking electronics 204 to 
commence communications using magnetic coupling via 
toroidal coil 200 in data mouse 10' and toroidal coil 214 at 
docking port 220. A mechanical stop 216 aids the user in 
aligning the data mouse with the coil and magnet of the 
docking port. 

Note that although this embodiment only depicts a light 
emitting diode 210 for indicating docking status, the other 
methods described above could also be employed. 
Fundamentally, the docking operation is similar to that 
described above in connection with the optical coupling 
embodiment. In this alternate embodiment, however, the 
means of detecting a connection, i.e., the reed relay, and the 
means of communicating, i.e., magnetic coupling of coils, 
are different. However, the balance of the logical connection 
of the data mouse to the computer system is the same. This 
alternate embodiment has the advantage of potentially con- 
suming less power and having greater tolerance for mis- 
alignment. 

To restate, presented herein is a docking system and 
method for automatically establishing secure wireless com- 
munication between a portable device and a selected intel- 
ligent device of a plurality of intelligent devices. A signifi- 
cant goal of the approach presented is ease of use. 
Specifically, this invention allows establishment of wireless 
data communications between devices in a manner that is 
user friendly and inexpensive to implement. An address 
identifier, and possibly an encryption key, is automatically 
exchanged between a portable device and a selected intel- 
ligent device upon docking of the portable device at a 
predefined docking area associated with the selected intel- 
ligent device. Through the use of limited range wireless 
communications, this information can be exchanged without 
also revealing the information to other intelligent devices 
not in sufficiently close proximity. In maximally secure 
situations, docking can be via a temporary wired connection 
for the exchange of the identifier address and encryption key. 

The docking approach presented can be applied to various 
portable devices, including a data mouse and personal 
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digital assistants. Again, the disclosed solution to establish- 
ing wireless connection largely relieves the user of any key 
entry requirements, as well as relieving the user of a need to 
assign addresses. In addition, by suitably setting up the 
possible address configurations, the probability of errant 
communications between a portable device and the plurality 
of intelligent devices in proximity thereto can be rendered 
negligible. 

Although specific embodiments of the present invention 
have been illustrated in the accompanying drawings and 
described in the foregoing detailed description, it will be 
understood that the invention is not limited to the particular 
embodiments described herein, but is capable of numerous 
rearrangements, modifications and substitutions without 
departing from the scope of the invention. The following 
claims are intended to encompass all such modifications. 

We claim: 

1. A docking system for establishing wireless connection 
between a first device and a second device, the first device 
comprising a portable device, said second device comprising 
one intelligent device of a plurality of intelligent devices to 
be disposed within a wireless communication range of said 
first device, wherein said first device is capable of wireless 
communication with any of said plurality of intelligent 
devices, said docking system comprising: 

first wireless communication means comprising part of 
the first device and second wireless communication 
means comprising part of the second device, said first 
and second wireless communication means for provid- 
ing wireless communication between said first device 
and said second device; and 

proximity docking means for automatically establishing 
secure wireless connection between the first device and 
the second device when the first device is brought 
within a predefined docking area of the second device 
so that said first device exclusively communicates with 
said second device of said plurality of intelligent 
devices, said predefined docking area being a limited 
area associated with said second device, said proximity 
docking means comprising means for automatically 
exchanging an address identifier between the first 
device and the second device when the first device is 
brought within the predefined docking area of the 
second device, wherein said secure wireless connection 
is maintained using said exchanged address identifier 
notwithstanding removal of the first device from the 
predefined docking area of the second device and 
notwithstanding use of the first device within commu- 
nication range of said plurality of intelligent devices. 

2. The docking system of claim 1, wherein said second 
device comprises a computer system and said docking area 
comprises a docking port coupled to said computer system. 

3. The docking system of claim 1, further comprising 
means for signalling a user once secure wireless connection 
has been established between the first device and the second 
device. 

4. The docking system of claim 1, further comprising a 
first encryption means associated with the first device and a 
second encryption means associated with the second device, 
said first and second encryption means allowing for encryp- 
tion of information to be transferred between the first device 
and the second device over the secure wireless connection, 
and wherein said system further comprises means for 
exchanging an encryption key between said first device and 
said second device when the first device is brought within 
the predefined docking area of the second device. 

5. The docking system of claim 1, wherein said first 
communication means and said second communication 
means each comprise electromagnetic communication 
means. 
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6. The docking system of claim 1, wherein said first 
communication means and said second communication 
means each comprise infrared communication means. 

7, The docking system of claim 1, wherein said means for 
automatically establishing wireless connection further com- 
prises means for establishing temporary hardwired connec- 
tion between the first device and the second device when the 
first device is brought within said docking port. 

8, The docking system of claim 1, wherein said predefined 
docking area of said second device comprises a predefined 
wireless docking range associated with said second device, 
wherein said proximity docking means comprises means for 
automatically establishing said secure wireless connection 
when said first device is brought within said wireless prox- 
imity docking area of said second device. 

9. The docking system of claim 8, wherein each intelligent 
device of said plurality of intelligent devices to be disposed 
within said wireless communication range of said first 
device has proximity docking means for automatically 
establishing secure wireless connection with said first device 2 o 
when said first device is brought within a predefined wire- 
less docking area associated with said intelligent device, and 
wherein said predefined wireless docking areas are non 



12. The docking system of claim 11, wherein said second 
device comprises a computer system and said docking area 
comprises a wireless docking port coupled to said computer 
system. 

13. The docking system of claim 11, further comprising a 
signaling device operable to signal a user once secure 
wireless connection has been established between the first 
device and the second device. 

14. The docking system of claim 11, further comprising a 
first encryption device associated with the first device and a 
second encryption device associated with the second device, 
said first and second encryption devices operable to allow 
for encrypted information to be transferred between the first 
device and the second device over the secure wireless 

15 connection, and wherein said system further comprises an 
encryption key exchanger operable to exchange an encryp- 
tion key between said first device and said second device 
when the first device is brought within the predefined 
docking area of the second device. 

15. The docking system of claim 11, wherein said first 
communication component and said second communication 
component each comprise electromagnetic communication 
components. 

16. The docking system of claim 11, wherein said first 



overlapping and each of said predefined wireless docking 

areas is within said wireless communication range of said 25 communication component and said second communication 

first device, wherein said first device exclusively commu- component each comprise infrared communication compo- 

nicates with said second device after being brought within nents. 

said predefined wireless docking area of said second device. 17 Th e docking system of claim 11, wherein said prox- 

10. The docking system of claim 9, wherein said second imity docking device is operable to establish a temporary 

device and each intelligent device of said plurality of 30 hardwired connection between the first device and the 



intelligent devices comprises a workstation, wherein said 
workstations are disposed in proximity to each other within 
said wireless communication range of said first device. 

11. A docking system for establishing wireless connection 
between a first device and a second device, the first device 35 
comprising a portable device, said second device comprising 
one intelligent device of a plurality of intelligent devices to 
be disposed within a wireless communication range of said 
first device, wherein said first device is capable of wireless 
communication with any of said plurality of intelligent 40 
devices, said docking system comprising: 

a first wireless communication component comprising 
part of the first device and a second wireless commu- 
nication component comprising part of the second 
device, said first and second wireless communication 45 
components operable to provide wireless communica- 
tion between said first device and said second device; 
and 

a proximity docking device operable to automatically 
establish a secure wireless connection between the first 50 
device and the second device when the first device is 
brought within a predefined docking area of the second 
device so that said first device exclusively communi- 
cates with said second device of said plurality of 



second device when the first device is brought within said 
docking port. 

18. The docking system of claim 11, wherein said pre- 
defined docking area of said second device comprises a 
predefined wireless docking range associated with said 
second device, wherein said proximity docking device is 
operable to establish said secure wireless connection when 
said first device is brought within said wireless proximity 
docking area of said second device. 

19. The docking system of claim 18, wherein each intel- 
ligent device of said plurality of intelligent devices to be 
disposed within said wireless communication range of said 
first device has a proximity docking device operable to 
automatically establish a secure wireless connection with 
said first device when said first device is brought within a 
predefined wireless docking area associated with said intel- 
ligent device, and wherein said predefined wireless docking 
areas are non-overlapping and each of said predefined 
wireless docking areas is within said wireless communica- 
tion range of said first device, wherein said first device 
exclusively communicates with said second device after 
being brought within said predefined wireless docking area 
of said second device. 



20. The docking system of claim 19, wherein said second 

intelligent devices, said predefined docking area being 55 device and each intelligent device of said plurality of 

a limited area associated with said second device, said intelligent devices comprises a workstation, wherein said 

proximity docking device comprising an address iden- workstations are disposed in proximity to each other within 

tifier exchanger operable to automatically exchange an said wireless communication range of said first device, 

address identifier between the device and the second 21. A method for establishing wireless connection 

device when the first device is brought within the 60 between a first device and a second device, said first device 

predefined docking area of the second device, wherein comprising a portable device and said second device having 

said secure wireless connection is maintained using a docking area and comprising one intelligent device of a 

said exchanged address identifier notwithstanding plurality of intelligent devices to be disposed within a 

removal of the first device from the predefined docking wireless communication range of said first device, wherein 

area of the second device and notwithstanding use of 65 said first device is capable of wireless communication with 

the first device within communication range of said any of said plurality of intelligent devices, said method 

plurality of intelligent devices. comprising: 
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(a) docking the first device within said docking area; and 

(b) automatically establishing wireless connection 
between the first device and the second device in 
response to said docking step (a) so that said first device 
exclusively communicates with said second device of 
said plurality of intelligent devices, said docking area 
being a limited area associated with said second device, 
said automatic establishing of wireless connection 
including automatically communicating an address 
identifier between said first device and said second 
device when said first device is docked within said 
docking area, wherein after removal of said first device 
from said docking area, said first device and said 
second device maintain said wireless connection for 
communication of information therebetween using said 
communicated address identifier and notwithstanding 
use of the first device within communication range of 
said plurality of intelligent devices. 

22. The docking method of claim 21, wherein said second 
device comprises a computer system and said docking area 
comprises a docking port coupled to said computer system. 

23. The docking method of claim 21, further comprising 
signaling a user once secure wireless connection has been 
established between the first device and the second device. 

24. The docking method of claim 21, further comprising 
a first encryption mechanism associated with the first device 
and a second encryption mechanism associated with the 
second device, said first and second encryption mechanisms 
allowing for encryption of information to be transferred 
between the first device and the second device over the 
secure wireless connection, and wherein said method further 
comprises exchanging an encryption key between said first 
device and said second device when the first device is 
brought within the predefined docking area of the second 
device. 
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25. The docking method of claim 21, wherein said auto- 
matically communicating comprises automatically electro - 
magnetically communicating said address identifier between 
said first device and said second device when said first 

5 device is docked within said docking area. 

26. The docking method of claim 21, wherein said auto- 
matically communicating comprises employing infrared 
communication to automatically communicate said address 
identifier between said first device and said second device 

10 when said first device is docked within said docking area. 

27. The docking method of claim 21, wherein said auto- 
matically establishing wireless connection further comprises 
establishing temporary hardwired connection between the 

15 first device and the second device when the first device is 
brought within said docking port. 

28. The method of claim 21, wherein said automatic 
establishing (b) includes automatically exchanging an 
encryption key between the first device and the second 

20 device in response to said docking (a), said encryption key 
being employed by said first device and said second device 
to encrypt information communicated therebetween on said 
wireless connection. 

29. The method of claim 21, wherein said first device 
25 comprises a data mouse. 

30. The method of claim 21, wherein said docking area 
comprises a docking port associated with the second device, 
and wherein said first device comprises a data mouse, and 
wherein said docking (a) includes docking said data mouse 

30 within the docking port by bringing the data mouse within 
physical contact of the docking port. 

***** 
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(57) ABSTRACT 

A system and method of operating a computer system 
manages and controls wireless devices through a wireless 
control subsystem. The wireless control subsystem includes 
a programming module to extend a base communications 
API of a multi-tasking operating system through a set of 
programming objects callable by at least one wireless- 
related application. The wireless control subsystem also 
includes a system module having a plurality of layers of 
linked programming objects which propagate information 
from object to object indicative of the occurrence of system 
level events related to the operation and/or status of the 
wireless devices. System level events are communicated 
from a wireless device to the system module and through the 
layers of objects within the system module. Information 
indicative of said system level events is further propagated 
from the system module to the programming module to the 
wireless-related application. 
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FIG. 3E 




11/06/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 30, 2003 Sheet 8 of 29 



US 6,628,965 Bl 



FIG. 4 



79 



81 



CONTROL CENTER MONITOR 
(ONLY ONE IS ALLOWED PER KERNAL PROCESS) 
THIS ONE DEFINES SECURITY RULES, ATTRIBUTES 
AND PROPERTIES FOR OTHER LOCAL OR REMOTE 
MONITORS 



z 



REMOTE CONTROL 
CENTER MONITOR 



80 



1 



REMOTE CONNECTION 
CROSSES NETWORK 
BOUNDARY (INTERNET) 



LOCAL MONITOR POSSESS 
A SUBSET OF FUNCTIONALITY AS 
DEFINED BY THE CONTROL 
CENTER MONITOR 



LOCAL 
CONNECTION 
(SAME MACHINE) 



LOCAL 
CONNECTION 

(SAME 
MACHINE) 




11/06/2003, EAST Version: 1.4-1 



U.S. Patent 



Sep. 30, 2003 



Sheet 9 of 29 



US 6,628,965 Bl 



FIG. 5 



APPLICATION 



-85 



TO/FROM EXCHANGE 



PIPE 
OBJECT 



FROM PROCESS PIPE 
(SEE FIG. 3B) 

TO PROCESS PIPE 
(SEE FIG, 3B) 




86a 



' SOCKET i 
OBJECT 



APP SOCKET i 
OBJECT 



86b 



11/06/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 30, 2003 Sheet 10 of 29 US 6,628,965 Bl 
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COMPUTER METHOD AND SYSTEM FOR 
MANAGEMENT AND CONTROL OF 
WIRELESS DEVICES 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The present application claims the benefit of U.S. Provi- 
sional Patent Application Serial No. 60/063,604 filed Oct. 
22, 1997 and U.S. Provisional Patent Serial No. 60/068,838 
filed Dec. 24, 1997, the disclosures of which is incorporated 
herein by reference. A portion of the disclosure of the 
present invention and U.S. Provisional Patent Application 
Serial No. 60/063,604 contain material which is subject to 
copyright protection. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

FIELD OF THE INVENTION 

The present invention relates to wireless devices such as 
wireless modems, wireless networks and personal data assis- 
tants (PDAs), and more particularly to a method and system 
for managing and controlling such wireless devices through 
a wireless control subsytem running on and extending a 
multi-tasking operating system. 

BACKGROUND OF THE INVENTION 

Traditionally, computers at remote locations communi- 
cated with one another through hard- wired or cable connec- 
tions. One such common connection is a computer network 
known as a LAN (local area network) by which computers 
are connected to one another through other intermediary 
computers such as servers and routers via physical cabling 
(i.e., twisted-pair wire, coaxial cables, fiber optic lines) to 
and from the computers. Other hard- wired connection meth- 
ods include connections by traditional modems which allow 
computers to communicate with one another over telephone 
or data lines. 

More recently, with the proliferation of cellular and 
wireless technology, there has been a dramatic increase in 
"wireless" computing whereby computers can communicate 
with one another without cable or wires over wireless or 
cellular networks. Wireless computing allows for increased 
mobility of a computer user since it allows computer trans- 
missions and communications from virtually any location 
where a wireless or cellular system is present. Today, 
wireless networks are prevalent almost everywhere in the 
world. With the increased use of laptop, notebook and 
palm-sized computers and PDAs, more and more individu- 
als and companies now desire to communicate and exchange 
data by wireless exchange. 

Although wireless computing is relatively new and con- 
tinues to gain popularity, various methods of programming 
for and configuring wireless devices have been developed. 
One such "first generation" method for creating software to 
handle wireless devices was through the use of so-called 
direct device access. Direct device access gave the program- 
mer the ability to have total control over the device. 
Unfortunately, a great deal of knowledge was required about 
the particular device and the network on which it operated 
as each device has its own unique method by which it is 
used. To make matters worse, each final software program 
which was developed was restricted to the particular device 
to which it was built. In order to switch networks or devices, 



each application would have to be re -written to accommo- 
date the differences in the network and/or device. 

"Middleware" (i.e., software that connects two otherwise 
separate applications) for wireless applications was then 

5 developed as the next step. By providing a common API 
(application program interface) upon which applications 
could be built, middleware applications could protect them- 
selves from changes in the selected wireless networks, 
system upgrades and wireless devices, provided that the 

10 middleware actually supported the new networks and 
upgrades. Middleware, however, was designed around the 
programming models of the time such as single-threaded, 
single- application operating systems like DOS (disk oper- 
ating system), with a single wireless device connected at a 

15 time. 

Further, middleware made use of a polling approach 
whereby the software would constantly send out signals or 
polling sequences to determine whether or not a relevant 
event occurred in the wireless system (such as an out of 
coverage situation, whether a modem was on-line, etc.) This 
polling paradigm used up precious computer cycles and 
resulted in constant looping of requests for status informa- 
tion. 

As operating systems evolved into multi-tasking 32-bit 
environments, such as Windows 95 and Windows NT, 
customers began to demand more from their software. At the 
same time, as mobile computing became more prevalent, the 
traditional approaches discussed above began to fall short. 
One solution was to simply port middleware to the new 
environments. However, this attempt did not take advantage 
of the new operating systems and all its features. Further, 
applications developed under a single-threaded, DOS pro- 
gramming model which were then "ported" to a multi- 
tasking environment were often difficult to successfully 
deploy. 

Attempts were also made to place industry standard 
interfaces in front of middleware's proprietary API. 
However, these attempts were only marginally successful 

40 and problems surfaced. Middleware today lacks the ability 
to handle system-level events or handle multiple applica- 
tions in a fashion appropriate for these environments. In 
order for middleware to truly fit into the new computing 
world, a port from a single-tasking environment is not 

45 enough. 

Accordingly, there exists a need for a new generation of 
wireless-enabling technology to make wireless communica- 
tions and programming easier and faster where direct device 
access and middleware cannot, and provide new features 
50 which allow the creation of applications which were nearly 
impossible to think about before. Such need is addressed by 
the present invention. 

SUMMARY OF THE INVENTION 

55 One aspect of the present invention provides methods of 
operating a computer system for managing and controlling 
wireless devices. Preferred methods according to this aspect 
of the invention include the steps of providing at least one 
wireless device connected to a computer, providing a multi- 

60 tasking operating system having a base communications API 
to the computer, providing at least one wireless-related 
application running on the computer for enabling wireless 
communications among the wireless device and wireless- 
related application, and providing a wireless control sub- 

65 system to the computer. The a wireless control subsystem 
includes a programming module extending the base com- 
munications API through a set of programming objects 
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callable by the wireless-related application, and a system operating system through providing a first set of COM 

module having a plurality of layers of linked programming objects; and actuating the computer by the wireless control 

objects which propagate information from object to object subsystem such that the COM objects are used by the 

indicative of an occurrence of system level events related to wireless control program subsystem to display graphical 

the operation and/or status of the wireless device. The s indicia to the base shell of the operating system indicating 

method further includes the steps of communicating the activation of the wireless control program subsystem, 

system level events from the wireless device to the system Prcfcrabl tbe base shdl of the ti lem ovides 

module; propagating m formation indicate of the system ^ hkal . user mterface ^ ^ yiag £ w ele . 

level events through at least some of the layers of objects ^ £ £ ux{ d ^ ^ inc a 

within he system modu e; and further propagating he ,„ control panel folder comaming ieons re p rese „,ing configu- 

information indicative of the system level events from he ^ m ^ of * ^ ^ fifst K{ q( cqm 

system module to the programming module ana trom me obje f ^ ^ 

extension module are configured to 

programming module to the wireless-related application. pr ^ de a foldef icQn m ^ COQtrol ^ fo]der containing 

In another preferred method of the present invention, deyice icong therdn representing me wire i ess devices and 

there is provided a method of operatmg a computer system 15 program icon in the panel folder for accessing 

for managing and controliing wireless devices which allows of ^ wireless CQntrol program subsystem by 

system level event propagation across two or more comput- se]ection of the progr am icon. Desirably, the first set of 

ers. Such method preferably includes the steps of providing COM objects are configured to place an additional program 

at least one wireless devxce connected to a first computer and icQn on the usef desktop . Further? the firsl set of C OM 

providing a second computer remote from the first computer, 20 objects arc also configured to disp i ay representations of the 

with the first and second computers being connected by a deyices folder and program icon in an exploring 

communications link. A multi-tasking operating system is window. 

provided to each of the first and second computers, and the ' , . L1 . , . . . , 4 , t 
multi-task operating system of the second computer includes More desirab y, the user desktop includes a task ray 
a base communications API, At least one wireless-related 25 re ?°" dls P ( lcons .TT*, f fr^V f 
application is provided which runs on the second computer extend * e °P e ; atlD f s ^ tem and firet ^iCOM objects 
for enabling wireless communications between the wireless are configured to locate a program icon in the task tray 
device and wireless-related application. The method further re S 10n u P on acUvatlon of the wireless control subsvstem - 
provides a wireless control subsystem to the first computer Another aspect of the present invention provides a method 
comprising a system module which has plurality of linked 30 of operating a computer system for managing and control- 
programming objects operative to propagate information Ung wireless devices including the steps of providing at least 
from object to object indicative of an occurrence of system one wireless device connected to a computer and at least one 
level events related to the operation and/or status of the wireless-related application running on the computer; pro- 
wireless device. Still further, the method includes the steps vidmg a multi-tasking operating system having a base shell 
of providing the second computer with a programming 35 and base communications API to the computer; and provid- 
module extending the base communications API through a ™g a wireless control subsystem to the computer. The 
set of programming objects callable by a wireless-related wireless control subsystem includes: a shell extension mod- 
application, communicating system level events from the *le extending the base shell of the operating system through 
wireless device to the system module, propagating informa- providing a first set of COM objects used by the wireless 
tion indicative of the system level events through at least 40 contro1 P r °g ram subsystem to display graphical indicia to 
some of the objects within the system module; and further the base shell of the operating system indicating activation 
propagating the information indicative of the system level of the wireless control program subsystem, a programming 
events from the system module to the programming module module extending the base communications API through a 
of the second computer across the communications link and set of programming objects callable by wireless-related 
from the programming module to the wireless-related appli- 45 applications for enabling wireless communications among 
ca tj on the wireless device and wireless-related applications, and a 

In another preferred aspect of the present invention, there svstem module havin § a P luralit J of Hnkcd Programming 
is provided a method of operating a computer system for ob J ects operative to propagate information indicative of an 
managing and controlling wireless devices including the occurrence of system level events related to the operation 
steps of: providing at least one wireless device connected to so and/or slatus of the wudess device throu S h the linked 
a computer; providing at least one wireless related computer programming objects of the system module to the program- 
application executable on the computer; and providing a ming objects of the programming module and then to at least 
wireless control subsystem to the first computer to actuate one application running on the computer, 
the computer to (i) provide a system module comprising a In a particularly preferred arrangement, the method fur- 
plurality of linked programming objects, and (ii) propagate 55 ther includes providing an industry standard module which 
information indicative of the occurrence of system level exposes one or more industry-standard programming inter- 
events related to the operation and/or status of the wireless faces to a programmer to enable development of custom 
device through at least some of the objects and up to the wireless applications which can communicate with the pro- 
applications running on the computer. gramming module and the system module. Such industry - 

In yet a further preferred aspect of the present invention, 60 stardard programming interfaces can include ActiveX, Win- 

a method of operating a computer system for managing and sock and/or OBDC. 

controlling wireless devices includes the steps of: providing Desirably, the programming objects of the programming 

at least one wireless device connected to a computer; module can include application socket objects which rep re - 

providing a multi -tasking operating system having a base sent single socket connections with each application, and the 

shell and base communications API to the computer; pro- 65 plurality of the linked programming objects can include a 

viding a wireless control subsystem to the computer includ- first layer of cable objects representing a communication 

ing a shell extension module extending the base shell of the link with a wireless device, a second layer of socket objects 
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representing a user created socket connection, and a third Another aspect of the present invention provides a method 

layer of process objects representing the link between the of transmitting wireless communication information from a 

system module and the programming module. In such as recipient computer connected to a recipient wireless device 

case, the wireless control subsystem can then actuate the ba ck to a sender computer connected to a sender wireless 

computer to: sense at the cable objects the occurrence of a 5 device to confirm receipt of user data sent from the sender 

system level event related to the operation and/or status of computer by an application running on the recipient com- 

the wireless device, send first signals from the cable objects P uter * ^ methc > d chides the ^P 5 of fonmn S one ° u r mor « 

indicative of the system level event to the socket objects, transmission packets m the recipient computer with each 

send second signals from the socket objects indicative of the P acket mchldin S a bl ?^ k of u f r d f P r0Vld ? d f b ? the 

! , to A t i * , j j , i • j recipient computer and transport confirmation data repre- 

system level event to the process objects and send third 10 ^ ^ ^ b ^ app {j catiori ^ning on the recipi- 

signals indicative of the system level event from the process ent ^ f of ^ ^ £f ock of ^ data; and transmit . 

objects to the application socket objects of the programming Uag me transmission packets from me recipient computer 

module, and from the application socket objects to the back to the sender cornput er via the recipient and sender 

application. wireless devices. 

Preferably, the system module is operative to propagate 15 Desirably, the transmission packets can be provided with 
through the objects a system level event indicative of when performance data representing the rate at which the recipient 
at least one wireless device is in an out-of -coverage area. wireless device can send and receive data, and load data 
Further, the wireless control subsystem can be configured to representing the amount of data being presently handled by 
hold in abeyance communications with a wireless device the recipient wireless device. Further, the step of transm it- 
determined to be in an out-of-coverage area until the system 20 ting occurs at a transmission rate which is varied in response 
module determines when at least one wireless device returns to performance characteristics of the transmission based on 
to a coverage area by sensing the occurrence of an the performance data. The step of transmitting includes also 
in-coverage system event. preferably includes transmitting a plurality of the transmis- 

A1 c t , # , t . sion packets and varying the number of packets being sent 

Also preferably, the system module is operative to propa- i iL * . . . . / & j . r . e & 

. r , , - ; t , i i . » t < to the recipient wireless device m response to pertormance 

gate through the objects real-time system level even* to * of &t reci ienl ^ictes device based on , he 

provide diagnostic information about the status of at least j Qad data 

one wireless device, and real-time diagnostic information, ^ transmission ke(s in ODe a t of the invemiori , 

such as registration status, signal strength and device desirably contain: dest i na ti 0 n address data representing the 

address, can be displayed on a display device of the com- identity of the recipient computer to receive the transmission 

puter in an on-screen diagnostic panel. packets, source address data representing the sender com- 

The system module can further include at least one wizard puter of the transmission packets, a block of user data 

program for automatic and simplified configuration and provided by the recipient computer, transport confirmation 

registration of at least one wireless device to the wireless data representing the receipt by the recipient computer of the 

control subsystem. entire block of user data, delivery notification data repre - 

Desirably, the wireless control subsystem allows at least 35 anting information provided back to the sender computer 

one the wireless devices to communicate simultaneously indicating successful receipt of the user data by the apph- 

with two or more applications. cation running on the recipient computer, performance data 

" . j representing the rate at which the transmission packets are 

Another aspect of the invention provides a second remote bd seQt and receivedj and load data repres enting the 

computer and at least one wireless-related application run- 40 num5er of transmission packets being concurrently received 

mng on the second remote computer, with the second remote by (he recipient w i re less device. These transmission packets 

computer being connected to the first computer via a com- are men transmitted from the recipient computer back to the 

munications link. Here, the wireless control subsystem is source computer via the recipient and sender wireless 

operative to allow at least one the wireless devices to devices. 

communicate simultaneously with at least one application 45 yet a further aspect of the present invention provides a 

running on the first computer and at least one application computer system for managing and controlling wireless 

running on the second remote computer. devices. The system according to this aspect of the invention 

Yet another aspect of the invention provides that the includes a computer and at least one wireless device con- 

wireless control subsystem allows at least one application nected to the computer. The computer includes memory 

running on the first computer to communicate with two or so means and processor means connected to the memory 

more wireless devices simultaneously. Preferably, a second means. The memory means includes OS memory means for 

remote computer is provided with at least one wireless- storing a multi-tasking operating system having a base 

related application, with the second remote computer being communications API, application memory means for storing 

connected to the first computer via a communications link, at least one wireless-related application for causing the 

and the wireless control subsystem is operative to allow at 55 processor means to enable wireless communications 

least one application running on the second remote computer between the wireless device and wireless-related 

to communicate with two or more wireless devices simul- application, and subsystem memory means for storing a 

taneously. wireless control subsystem. The wireless control subsystem 

In a further aspect of the invention, at least one wireless includes a programming module for causing the processor 
device can be operable with a first wireless network protocol 60 means to extend the base communications API through a set 
and at least one wireless device can be operable with a of programming objects callable by at least one wireless- 
second, different wireless network protocol. Further, the related application, and a system module comprising a 
system module utilizes sockets for data transport. Still plurality of layers of linked programming objects for caus- 
further, the wireless devices can be assigned a unique ing the processor means to propagate information from 
numeric address, wherein the system and shell extension 65 object to object indicative of an occurrence of system level 
modules are operative to match the numeric addresses to events related to the operation and/or status of the wireless 
user-friendly monikers. device. 
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The system module is further operative to cause the 
processor means to communicate system Level events from 
the wireless device to the system module, propagate infor- 
mation indicative of the system level events through at least 
some of the layers of objects within the system module, and 
further propagate the information indicative of the system 
level events from the system module to the programming 
module and from the programming module to at least one 
wireless-related application. 

Finally, a still further aspect of the present invention 
provides a computer system for managing and controlling 
wireless devices including a computer and at least one 
wireless device connected to the computer. The computer 
includes memory means and processor means connected to 
the memory means. The memory means includes (i) appli- 
cation memory means for storing at least one wireless- 
related application for causing the processor means to enable 
wireless communications between the wireless device and 
the wireless-related application; and subsystem memory 
means for storing a wireless control subsystem having a 
system module including a plurality of layers of linked 
programming objects for causing the processor means to 
propagate information indicative of the occurrence of sys- 
tem level events related to the operation and/or status of the 
wireless device through at least some of the objects and up 
to at least one application. 

These aspects and other objects, features and advantages 
of the present invention will be more readily apparent from 
the detailed description of the preferred embodiments set 
forth below, taken in conjunction with the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a block diagram depicting the various layers 
and modules used in connection with the present invention. 

FIG. 2 shows a functional block diagram depicting appa- 
ratus which can be used in accordance with the present 
invention. 

FIG. 3 shows a block diagram showing the relationship 
among the various modules and components used in accor- 
dance with the present invention. 

FIG. 3A shows the exchange place object components of 
the system module. 

FIG. 3B shows the process object components of the 
system module. 

FIG. 3C shows the core place object components of the 
system module. 

FIG. 3D shows the cable object components of the system 
module. 

FIG. 3E shows the socket object components of the 
system module. 

FIG. 3F shows the monitor object components of the 
system module. 

FIG. 4 shows the components of the monitor module. 

FIG. 5 shows the components of the programming mod- 
ule. 

FIG. 6 shows the components of the shell extension 
module. 

FIG. 7 is a block diagram showing the difference in data 
transport confirmations between the present invention and 
with middleware. 

FIG. 8 shows a Windows control panel window including 
the wireless devices and wireless networking program icons 
added by the present invention. 
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FIG. 9 shows a Windows Exploring window exploring the 
wireless devices folder. 

FIG. 10 shows a screen used in the Add Wireless Devices 
Wizard of the present invention. 
5 FIG. 11 shows a screen used in the New Domain Wizard 
of the present invention. 

FIG. 12 shows a screen used in the New Host Wizard of 
the present invention. 
!0 FIG. 13 shows the Windows task tray with icons showing 
the running of current applications. 

FIG. 14 shows the placement of the icon Wireless Net- 
working on the user desktop of a Windows CE operating 
system. 

15 FIG. 15 shows a Wireless Networking properties sheet. 
FIG. 16 shows a number of wireless devices objects. 
FIG. 17 shows a Windows Exploring window exploring 
the wireless networking object, 
20 FIG. 18 shows a Windows Exploring window exploring 
the host object DMD. 

FIG. 19 shows a block diagram of the routing capability 
of the present invention. 

FIG. 20 shows an initial screen of the installation process 
25 of the wireless control program subsystem of the present 
invention. 

FIG. 21 shows an further screen of the installation process 
of the wireless control program subsystem of the present 
invention. 

FIG. 22 shows the provision of new desktop icon on the 
desktop of a Windows operations system. 

FIG. 23 shows a pop -up menu appearing from the desktop 
icon of FIG, 22 when selected. 
35 FIG. 24 shows an icon in the Windows task tray showing 
the running of the wireless control program subsystem of the 
present invention. 

FIG. 25 shows a pop-up menu appearing from selection of 
the program icon in the task tray of FIG. 24. 
40 FIG. 26 shows a Windows Exploring window exploring 
the wireless networking object. 

FIG. 27 shows the Add Wireless Device Wizard window 
launched from selection of the Add Device icon. 
45 FIGS. 28-34 show screens displayed in connection with 
the Add Wireless Device Wizard. 

FIG. 35 shows a Wireless Devices window displaying the 
new object SampleDevice created via the Add Wireless 
Device Wizard. 

50 FIG. 36 shows a pop-up menu appearing from selection of 
the object SampleDevice with the Properties command 
selected. 

FIG. 37 shows a property sheet for the object Sample- 
Device. 

55 FIG. 38 shows a pop-up menu appearing from selection of 
the object SampleDevice with the Delete command selected. 

FIG. 39 shows a pop-up menu from the selection of the 
Wireless Networking icon with the open command selected. 
60 FIG. 40 shows the Wireless Networking window display- 
ing an Add Domain object which is seen after opening the 
Wireless Networking icon of FIG. 39. 

FIG. 41 shows a screen used in the New Domain Wizard. 
FIG. 42 shows the display of the new object SampleDo- 
6 5 main added via the New Domain Wizard. 

FIG. 43 shows a pop-up menu from the selection of the 
SampleDomain icon with the open command selected. 
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FIG. 44 shows the SampleDomain window displaying an OS such as Windows NT and which communicate with 

Add Host object which is seen after opening the Sample- wireless devices. Such computers can include, for example, 

Domain icon of FIG. 43. PCs, Macintoshes, Power-PCs, palm-based PCs, PDAs, 

FIGS. 45-47 show screens used in the New Host Wizard. workstations or the like. 

t-t^ ao ^ i j . | ft . u* * c i it ♦ 5 As shown in FIG. 2, representative system hardware is 

a? a' ,t m S ~ 1 J Sam P leHost illustrated for use with the present invention, including a 

added via the New Host Wizard. conventional computer 20 into which computer software 

FIG. 49 shows a properties sheet for the host DMD. implementing the wireless control program subsystem is 

FIG. 50 shows a pop-up menu from selection of the loaded via the usual manner such as by floppy disks 21 or 

program icon in the task tray with the Devices command 10 CD-ROM 22 and typically stored on an internal hard drive 

selected. or other attached internal or external mass storage device. 

FIGS. 51-54 show the Wireless Devices windows views Computer 20 includes the typical input devices such as 

resulting from the selection of the Devices command from keyboard 23, floppy disk drive 24, CD-ROM drive 25, and 

FIG. 50. mouse 26. Computer 20 also includes a display device or 

is monitor 27 and internal ROM and RAM memory (not 

DETAILED DESCRIPTION OF PREFERRED shown) which stores the various modules of the present 

EMBODIMENTS invention when activated or loaded. The computer 20 

executes the various modules of the wireless control pro- 

Ihc present invention not only provides a programming subsystem of the present invention via control by the 

interface for wireless devices but also itself comprises an 2Q uter > s interaal microproC essor. 

'operating system extension for handling configuring and ^ to ^ ^ fa & modcm 2g 

communicating with wireless devices. Configured as a wire- M co _ icates t0 otner wireless devices> such as 

close to and m tact extends tne computer s 3Z on winaows wireless PDA3 o also with an internal wireless modem. Such 

based operating system (e.g.. Windows 95. N 1, Lb, yo, etc.) . • j- * i * • n 

i * j i_ \ \ B t - \ ' ,' CJ ,( 25 communication occur via radio-frequency signals typically 

as explained below. As an operating system ("OS ) , . . . z 1 3 Jr 

\ 4 . . r n ir* l j'i transmitted over a wireless network, 

extension, the present invention allows itseli to be readily T _ . - x . , , 

j * it_ ,,7- j ~ . i n i a r i I- Overview of Modules 

configured via the Windows Control Panel and Explorer. ™ . , . t , . , 

6 r The wireless control program subsystem of the present 

Once running, the wireless control program subsystem is invention preferably includes two modules for extending the 

be visible in the Windows Task Tray and can be activated for 30 Wm d ows OS, including a Windows Shell extension module 

diagnostic reporting and viewing of the running devices and and a programming module. 

connections. The wireless control program subsystem is The shell extension module 1 extends the Windows OS by 

advantageously designed to react appropriately to system extending the Windows Shell already packaged with the 

events such as shutting down Windows and power manage- windows operating system. With this shell extension, the 

ment functions. Thus, the wireless control program sub- 35 user can configure an d view all of the current wireless 

system of the present invention provides an infrastructure, devices attached to the system as well as manipulate the 

not simply an API like middleware. This infrastructure items such as an "address book" (explained in detail further 

provided by the present invention preferably has a multi- below). Also, via the shell extension module, the Windows 

layered, modular format, with some of the layers or modules Task Tray ( the status 5ox typify m the lower right comer 

being used by the end-user, some by the programmer, and 40 0 f the Windows desktop with the clock) may contain an icon 

some by the program itself. which allows users to readily see running diagnostics and 

Referring now to FIG. 1, the infrastructure of the present configure dynamic properties of wireless devices, 
invention can be broken down into several discrete layers or The programming module 2 also extends the Windows 
modules, including a shell extension module 1, a program- OS by extending Winsock (short for Windows Socket), the 
ming module 2, a system module 3 and an industry standard 45 default API provided by Windows, and provides wireless- 
interface module 4. Applications 5 can be provided to specific calls. With the programming module, objects are 
interface with certain modules (e.g., system module, shell provided through the C++ class library to programmers who 
extension module) and can be created using the modules can readily use this module to build applications which 
(e.g., the industry standard module and the programming communicate with the system natively instead of using a 
module. Each of these modules are described in more detail 50 industry standard interface. 

below. A Windows Kernel 6, provided by the Windows The system module 3 provides software objects and 

operating system, is also shown as cooperating with the additional GUI elements to the wireless control program 

other modules of the present invention. The Windows Ker- subsystem and controls the actual wireless devices attached 

nel is the operating system's central module that loads first t 0 the computer. It can treat the wireless devices as system 

and remains in the computer's main memory. It provides 55 "resources" and take advantage of other system resources 

essential services, such as memory management, process and events such as hardware interrupts. The system module 

and task management and disk management, which are provides visual indications of the control of the wireless 

required by other parts of the Windows operating system and devices attached to the computers on which wireless control 

other applications. program subsystem is running. 

The individual modules of the present invention are 60 The industry standard interface module 4 exposes to the 

written and designed to interact and cooperate with one programmer standard interfaces in which to program, and 

another. Together, the modules (either a selection of modules allows development of industry-standard programs using 

or all of the modules) collectively form the comprehensive ActiveX controls. This module preferably includes several 

wireless control program subsystem of the present inven- proprietary ActiveX controls such as those offered in 

tion. The wireless control program subsystem is preferably 65 MobileX™, a wireless Windows development tool offered 

installed through software adapted to run on one or more by Dynamic Mobile Data Systems, Inc. of Somerset, N.J. 

general purpose, programmable computers running a 32-bit (hereinafter "DMD"). This layer also can include interfaces 
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such as a true Winsock 2 driver (32 bit Winsock) and 
preferably MobileSockets™ offered by DMD and a wireless 
ODBC driver such as MobileQuery™ also offered by DMD. 

The specific details of the various modules of the wireless 
control program subsystem are now described below. 
II. Details of the Modules 

The interconnection of each of the modules of the present 
invention are more particularly illustrated in block diagram 
form in FIG. 3. Thus, FIG, 3 illustrates the cooperation and 
linking of the major sections of the present invention are 
shown in block diagram form, including shell extension 
module 31, system module 32, programming module 33, 
industry standard module 34, database interface 35, database 
36, hardware components 37 and applications 38a and 38k 
A. The System Module 

The system module 32, as well as the other modules of the 
wireless control program subsystem, use an object-oriented 
approach whereby the components in the wireless control 
program subsystem are represented as "objects." An object 
is definable by the programmer in the chosen object-oriented 
programming language and is generally any item that can be 
individually selected and manipulated. An object is self- 
contained and contains both data and procedures to manipu- 
late the data. 

Object-oriented programming refers to a type of program- 
ming in which programmers define not only the data type of 
a data structure, but also the types of operations or functions 
that can be applied to the data structure. In this way, the data 
structure becomes an object that includes both data and 
functions. Programmers can then create relationships 
between one object and another. For example, objects can 
inherit characteristics from other objects. One of main 
advantages of object-oriented program is that it allows 
programmers to create modules that do not need to be 
changed when a new type of object is added. A programmer 
can simply create a new object that inherits many of its 
features from existing objects. 

The system module 32 comprises six main component 
sections, including exchange place object components 32 A, 
process pool object components 32B, core objects 32 C, 
cable pool object components 32D, monitor components 
32E and socket pool object components 32F. The details of 
each of these sections are shown in more detail in FIGS. 3A 
through 3F which express the details of the system module 
at the object level such that one of ordinary skill in object- 
oriented programming with knowledge of wireless system 
can create the necessary software program which imple- 
ments the system module. This is also the case with the 
programming module 33 which is shown at its object level 
at FIG. 5. 

Turning now to FIG. 3A, exchange place object compo- 
nents are shown, including exchange place object 40, 
exchange place thread 41, stop event 41a and exchange 
place IPC 42. The exchange place object components are 
used for the initial connection of the application (or process) 
to the system module and are responsible for creating 
"process objects" which are objects that represent the run- 
ning of an application or process (i.e., an executing 
application). Thus, it should be appreciated that the same 
application could be launched two or more times and thus 
each instance of the application would be a separate "pro- 
cess." 

Exchange place object 40 is the component which is 
responsible for establishing the connection between the 
system module and the programming module. Exchange 
place thread 41 is responsible for inter-process communi- 
cations within this object. Stop event 41a is provided for 
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stopping execution of the thread. Finally, exchange place 
IPC 0nterProcess Communication) 42 comprises WIN32 
system objects (event, mutex and map) which are used 
within the exchange place object, IPC objects provide the 

5 capability of WIN32 operating systems to allow one process 
to communicate with another process. The processes can be 
running on the same computer or on different computers 
connected through a network. IPC enables one application to 
control another application, and for several applications to 
share the same data without interfering with one another. 
IPC is used in multiprocessing systems, but it is not found 
in single -process operating systems such as DOS. 

Together, the exchange place object components are 
responsible for the initial connection of a launched applica- 
tion to the system module. Once the application is launched 

15 and recognized, the application identifies itself to the system 
module by providing a process ID. If an identical application 
is re-launched such that the same application is running in 
two or more instances, each instance will be assigned a 
process ID. 

20 The creation and destruction of process objects in com- 
municated to process pool object components as shown in 
detail FIG. 3B. Process object pool 45 represents a collec- 
tion of process objects 45a, 45£>, 45c, etc. Each process 
object represents an a process or running of an application. 

25 For instance, process object 45a might represent Microsoft 
Excel, process object 45b might represent Lotus Notes and 
process object 45c might represent another execution of the 
same Lotus Notes application. Pipe object 46 is provided 
which is responsible for full-duplex data communications 

30 between the system module and the programming module. 
Pipe object 46 contains pipe thread 47 which is the thread 
responsible for the inter-process communications and also 
contains stop event object 47a and queue 48 which is an 
event-controlled storage for buffering data between the pipe 

35 thread and a socket pool object (see FIG. 3F). Stop event 
object is provided to stop execution of the pipe thread. Pipe 
object also contains pipe object IPC 49 which also contains 
WIN32 system objects (event, mutex, map and queue 
objects) used within the pipe object. Also provided is anchor 

40 object 50 for the list of process objects. 

Turning to FIG. 3C, the core object components are 
shown, including core object 51, which is an object that acts 
as a place holder for all of the objects within the system 
module, and queue 52 which is a data and event queue used 

45 to serve a single monitor. Core object 31 points to other 
objects in the system module including exchange place 
object (FIG. 3A), process pool object (FIG. 3B), monitor 
object (FIG. 3E) and Socket pool object (FIG. 3F). 
As shown in FIG. 3D, cable pool object 54 represents the 

50 collection of cable objects 54a, 54b, 54c, etc. A "cable" is a 
term used to represent a send/receive communication link. 
Cable object 54a, for example, includes device object 55 
which is derived from network object 56. Device object 55 
represents vendor and model specific implementation (e.g., 

55 X.25 direct wireless modem) of the wireless devices, prop- 
erties and methods. Network object 56 represents a network 
specific implementation of the wireless devices, properties 
and methods (such as the Mobitex network) and is in turn 
derived from cable object 54a. Cable object 54a further 

60 includes cable base class object 57 which represents the 
implementation of the generic wireless devices, properties 
and methods. Each cable object includes a wire anchor 58a 
which connects to wires 58 which represent remote routers 
relative to a particular cable within the system module. 

65 Through the use of multiple wires 58, the present invention 
can allow a single application or process to communicate 
with multiple routers and devices. 
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Cable pool object includes a cable anchor 67 which 
connects to each cable object. Each cable object in turn 
connects to datalink level object 59 which connects to frame 
base class object 60. Datalink level object 59, which is 
derived from frame object 60 represents the infrastructure 
specific implementation of the datalink layer, properties and 
methods. Frame base class object 60 is the implementation 
of the generic datalink layer, properties and methods. Frame 
base class object 60 thus serves a holding object for frames 
of data and datalink level object 59 serves as a passthrough 
object for passing the frame to the cable object. 

Frame base class object 60 is in tum connected to com- 
munications link object 61 which is derived from the com- 
munications link base class object 62 which is the generic 
representation of the generic communications layer, prop- 
erties and methods. Communications link object 61 also 
includes 10 thread 63, virtual thread 64 and queues 63a and 
63b. IO thread 63 is the thread which interfaces with the 
system interface to the hardware device driver. Virtual 
thread 64 is the thread which is responsible for event and 
data propagation up to the application. 

System driver 65, which is linked to communications link 
object 61, is a collection of WIN32 and third party hardware 
drivers which is the program which controls the modem or 
hardware device 66. Hardware device is a device such as an 
Eicon X.25 card, Ethernet card or other modem or network 
adapter or a UART. A UART (Universal Asynchronous 
Receiver-Transmitter) is a component that handles asyn- 
chronous serial communication to manage the serial ports. 
All internal modems have their own UART. Cable pool 
object 54 is linked to socket pool object components as 
shown in FIG. 3F. 

Socket pool object components are used to associate 
hardware events with the particular socket. FIG. 3E thus 
shows the socket pool object components, including socket 
pool object 70, which represents the collection of socket 
objects 70a, 70b, 70c etc. Socket objects are objects repre- 
senting a user-created socket within the system module. 
Socket pool object 70 also acts as a "parent" for the service 
thread 71 and socket and routing thread 72. Service thread 
71 is the thread servicing time interval-based requests origi- 
nated by the socket pool and cable pool objects. Socket and 
routing thread 72 is the thread which services time interval- 
based requests from the sockets. Queue 74 is provided which 
is the servicing queue for the process pool object. Socket 
pool object 70 is thus operative to associate an event then 
route information about the event to the given process or 
application. Socket pool object components are linked with 
core objects (see FIG. 3C), process objects (see FIG. 3B) 
and cable pool objects (see FIG. 3D). 

Referring now to FIG. 3 F, monitor object components are 
shown, including monitor object pool which includes the 
collection of monitor objects 77a, 77b, 77c, etc. Monitor 
object pools linked with the core objects from FIG. 3C. 
Monitor objects are components which are responsible for 
the connection to a single monitor instance. Monitor objects 
provide information to monitor module 39 which enable that 
module to monitor the status and behavior of the commu- 
nications and also provide control based on the monitoring. 
For instance, conditions that can be actively monitored 
include how many packets have been sent and delivered. 
Furthermore, this monitored information is then available to 
programmers who can build in control to their software 
based on the monitoring of transmissions and communica- 
tions. 

FIG. 4 illustrates the monitor module 39 in greater detail, 
and includes control center module 79, local monitor 80 and 
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remote control center module 81 . Control center monitor 79 
is the monitor which possesses controlling privileges which 
defines security rules, attributes and properties for other 
local or remote monitors. Local monitor 80 represents the 
process which reflects wireless extension activities, status 
and operations running on the same computer, and possesses 
a subset of the functionality as defined by the control center 
monitor. Remote control center monitor represents the pro- 
cess which reflects wireless extension activities, status and 
operation to a remote computer over a remote connection, 
such as a LAN, WAN and/or across network boundaries 
such as via the Internet. 

Programming module, shown in FIG. 5, includes an 
application 85 which is any application which uses the 
programming module. The programming module also 
includes application socket objects 86aand86£> each which 
represents a single socket connection or communication 
line. Application socket objects are links to the C++ class 
API 87 which is the interface of msocket.DLL, the dynamic 
link library system object which contains the implementa- 
tion of the C++ class API. 

The C++ class API provides the programming interface 
which allows applications to operate via sockets. Pipe object 
89 is provided which is the programming module counter- 
part for the pipe connection used by the system module. The 
pipe object 89 includes pipe thread 90 and virtual thread 91 
along with queue 92, queue 93 and not empty event indicator 
94. Pipe thread 90 is the thread responsible for data 
exchange between the external process queue and virtual 
thread queue. Pipe thread 90 is linked with process pipe 
object (see FIG. 3B) and thus communicates with the system 
module. Virtual thread 91 is the thread which is responsible 
for event propagation up to the application via application 
socket objects 8 6 A, 86B, etc. The header files for the C++ 
class API is listed herein at Appendix A, which include 
header files MAddress.h, MEvent.h, MName.h, 
MProviderEvent.h, MSocket.h, MSocketCodes.h and 
MSocketErrors.h. 

With the programming module, the system module gen- 
erates an event and associates an event with the proper 
socket. Information is then passed to the pipe thread 90. The 
data and events associated with the event is then stored in 
queue 92. The virtual thread 91 then picks up the data and 
events upon ascertaining that not empty event 94 is satisfied 
(i.e., data and events are present in queue 92). Then, the 
event is fired to the application associated with the socket. 
The application then, in turn, gives data back to queue 93 
which then goes back out to the process pipe object via pipe 
thread 90. 

When an application is launched for the first time, the 
application uses msocket.DLL to find out whether an 
exchange place object has been created. If not, msocket.DLL 
will start the system module which will then create the 
exchange place object. The exchange place object then looks 
for the process ID among the processes running and if it 
finds none, a new process must be created and a connection 
to it established. 

Referring back to FIG. 3, database interface 35 is shown 
which provides access to database 36 and serves as the link 
between the system module 32 and shell module 31. Data- 
base 36 is the storage used by the database interface and 
stores all of the configuration and setting information 
handled by the present invention, such as modem 
parameters, names of hosts, socket numbers, etc. Database 
interface 35 is a COM object component which provides 
programmatic access to the wireless extensions database. 
Database interface 35 also allows mutually exclusive access 
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by the shell and system modules and is operative to lock a appropriate process object (FIG. 3B). From the process 
record, allow for a change to the record, and unlock the object, the information is then sent to the msocket.DLL pipe 
record, all without allowing access to the record. thread 90 of the programming module 33. At the program- 
Shell module 31 contains the components which are ming module, the event is then associated with an applica- 
responsible for wireless extension configuration. Referring 5 lion socket object and routed to the application (process) via 
to FIG. 6, the shell module includes the Windows 32-bit the C++ class API. 

operating system shell 100, namespace extensions 102, An example of a communication from an application 

control panel interface 103 and desktop interface 104. sending data to a remote location using the present invention 

Finally, hardware 37 represents wireless and wired com- is now described for illustration purposes. First, the appli- 

munication infrastructure including wireless modems con- 10 cation (such as an e-mail application) communicates with 

nected via the serial or PCMCIA port, X.25 (a data transfer exchange place object components. Next, a process object is 

standard for packet-switching networks), TCP/IP or other created which represents the process or execution of the 

direct connection. e-mail application. A socket object is then created which 

While applications can communicate directly with the specifies the destination address of the remote computer to 

programming module 33 as shown in FIG. 5, applications, is where the data will be sent. Next, the proper cable object is 

such as application 38a (FIG. 3) can also gain access to the selected which specifies which wireless modem (perhaps out 

programming module via industry-standard module 34. of a pool of several modems) to use to communicate with the 

Thus, using the programming module, the industry-standard socket. Finally, the data is sent across the socket to the 

module provides programmatic access through industry modem and through the wire to the remote computer, 

standard interfaces such as Winsock 1.1, Winsock 2.0, 20 The objects described above follow well-accepted object 

ActiveX and ODBC. paradigms such as "inheritance" (properties inherited or 

The present invention provides for the propagation of derived from an underlying object such that if the underlying 

system events, through the defined objects, up through each object is changed, the derived objects will change as well) 

layer of the OSI (Open System Interconnection) model or and "polymorphism" (a program's ability to process objects 

standard for communications. OSI, an industry recognized is differently depending on their data type or class). Thus, the 

model, defines a networking framework for implementing wireless control program subsystem is designed to be highly 

protocols in seven layers. These layers include: physical extensible and anticipate future wireless networks and 

(e.g., a wire); data link (e.g., serial port); network (e.g., devices. 

packets); transport (e.g., TCP/IP); session (e.g., an FTP The device driver object takes into consideration all 

session); presentation (e.g., Windows OS); and application 30 devices and/or wireless network specific features. Each 

(e.g., e-mail program). With the objects, system events are device is treated and handled specially in an object to insure 

passed from one layer to the next, starting at the physical the optimal usage of the device and network infrastructure, 

layer and proceeding to the top layer in the hierarchy. Events In this manner, the present invention allows each modem to 

can not only be passed among the modules to applications utilize the most reliable and least expensive method of 

running on the same local computer, but events can also 35 transmitting the network's raw packets. Thus, through high 

bubble up through the objects to applications running on object interaction, the present invention can handle any 

remote computers. combination of transports, devices, and network protocols. 

An example of the propagation of a system event is now Using hardware interrupts which are signals informing a 

described. The event, here the "event" of an out-of-coverage program that an event has occurred, the wireless control 

situation of a wireless modem, starts at the hardware device 40 program subsystem of the present invention therefore uses 

66 (FIG. 3D) whereby a wireless modem, which contains an event-driven paradigm. Namely, the system module of 

firmware, causes signal to be sent indicative of its out-of- the wireless control program subsystem can "bubble up" or 

coverage condition when the modem has traveled to a relay information about an event from object to object, 

remote location, and a pin is set to high on the modem's across modules (and even across computers) and eventually 

serial port. The RS-232 port of the computer to which the 45 to the application(s) for virtually any change in condition, 

modem is connected receives data serially from the modem. including out-of-coverage situations, device wire 

The Windows system driver 65 then fires an event to the disconnects, over-heating, etc. With this feature, applica- 

communications link base class object 62 whereby serial tions running on a computer along with the wireless control 

data is collected in a buffer (queue 63a) by IO thread 63, and program subsystem do not have to poll the wireless device 

then sent via queue 63£> to virtual thread 64 which passes the 50 as they did with middleware. This creates many advantages, 

data to frame base class object 60. Frame base class object such as saving CPU cycles, giving an exact representation of 

60 in turn collects the data until a frame of data is created. the wireless happenings, saving battery life on the device 

To collect the frame of data, the data is read in bytes into the and the CPU, and allows applications to be written more 

buffer until a trigger byte is sensed indicating that a frame of intelligently. As applications have the choice as to which 

data is being sent. Once the trigger byte is sensed, all of the 55 events are important to it, applications can be programmed 

bytes of the frame are collected until an end of frame trigger to filter all wireless events down to a sub-set which is 

byte is sensed. important to the particular application. Therefore, with the 

The frame, containing data which represents the system present invention, applications do not have to process every 

event, is then sent from datalink level object 59 which acts possible event if it is not important to the application, 

as a passthrough to cable base class object 54a, which 60 The present invention is thus uniquely attuned to the 

represents the communication link with the modem (e.g., occurrence of wireless events. For instance, applications 

X.25 Direct) and the carrier (e.g., Mobitex MPAK), through request messages to be sent, and, if the present invention 

to the cable pool object 54 via cable anchor 67. knows that an out-of-coverage situation exists, it will not 

Next, the frame from cable pool object 54 is sent to socket attempt to send data but can instead place the messages in a 

pool object 70 (FIG. 3E) which associates the hardware 65 pending queue. As soon as the system module determines 

event with the particular opened socket object. The socket that the device is once again in coverage, it will then send 

and routing object 72 then passes the information onto the the message. This has clear advantages over middleware 
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which uses a "try-and-wait" paradigm and will continue to application. This eliminates many variables and after-the- 

attempt to use the modem even when it is out of coverage. fact debugging scenarios. If a user has a problem, he or she 

Thus, with the system module of the present invention, a can simply click over to the diagnostic panel, gel a clear 

programmer can create, for example, an application which vision of what is going on, and fix what is wrong even while 

"sleeps" until it is notified via the system module that 5 the application is still running. 

communications to the desired remote host is possible. Additionally, all of the diagnostic information is available 

Using most middleware, by contrast, applications would through the programming tools. Therefore, if an application 

have to poll for this situation and could never sleep. A developer decides to provide diagnostics to the user or wants 

programmer could also write an application which immedi- to record the diagnostic information into a private informa- 

ately responds to the instant a device is detached from the 10 tion store, this is also possible. Further, depending on what 

computer. Again, most middleware would have to poll for kind of problem is found, the application can attempt to fix 

this situation and would not be able to tell why the computer the problem since it can be provided with more detailed 

could no longer communicate with the device; only that it knowledge as to the error or a even automatically call for 

could no longer communicate. help. 

The wireless control program subsystem of the present 15 With the system module, wireless devices can be provided 

invention further allows a programmer to write an applica- with user-defined names for better diagnostic reporting, 

tion which sits idle until it is placed in a docking station Error messages thus could read, for example, "Modem with 

where, for instance, a truck-mounted modem exists. Middle- the scratch is having trouble connecting because the RS-232 

ware would again have to poll for this situation, attempting connection is absent" rather than a hard to decipher message 

to connect to the modem continuously. In situations where 20 such as "Cannot connect to COM1" as many middleware 

the device was docked but for some reason could not logs will report. In fact, certain middleware will report the 

communicate with the modem, middleware could not dif- same error message for many different errors. The diagnostic 

ferentiate between these situations. An application could reporting of the present invention advantageously uses an 

likewise be written that determines that a device is not in object-oriented approach to give an exact picture of what is 

coverage in one network infrastructure and automatically 25 happening at all times. 

checks coverage on another available network infrastruc- Because the present invention is really an infrastructure or 
ture. By doing this, an application can incorporate its own operating system extension, it can utilize "application rout- 
least-cost routing. ing" (explained below) to simultaneously deploy a third 
The wireless control program subsystem of the present party application while developing a custom-built applica- 
invention can be viewed as a wireless product itself as it can 30 tion. In addition, secondary applets (programs that can be 
run without any applications. Namely, once installed, the executed within another application but not directly execut- 
system module already has the ability to connect any con- able from the operating system) can be built later to run on 
figured devices in the system and register them with the the mobile device which will run smoothly with any cur- 
networks. By simply adding a wireless device and opening rently running applications. This is because all of these 
the subsystem's interface with a right mouse click, users can 35 applications are written using "sockets'' (software objects 
immediately tell whether the wireless device is activated for that act as middlemen to connect an application to a network 
the particular network as well as other items such as wireless protocol) instead of locking up a communications port as in 
network coverage checks, battery level indication, middleware solutions. 

diagnostics, etc. Through the system module, the present invention can be 

The system module also supports a full range of system 40 reconfigured without the need to modify applications. When 

diagnostics. Without requiring the development of an enhancements are made, applications will benefit from these 

application, the user can obtain diagnostic information about enhancements without any need to change to software, 

the wireless device and the network such as registration Automatic upgradability can also be utilized such that the 

status, signal strength, device address, etc. After inserting a present invention can automatically upgrade itself. Thus, the 

configured wireless device, the user can instantly tell if the 45 wireless control program subsystem of the present invention 

device is valid on the network and if the device is in is built ready for new wireless networks and devices. Using 

coverage before any user applications are even started. a driver metaphor, the present invention can accept new 

The system module also facilitates trouble -shooting. A devices as they become available and users can utilize the 

responsive customer service representative requires that full features of the present invention in porting from one 

when problems do occur with an application, there is an 50 network to another without needing to change the applica- 

effective mechanism to obtain the diagnostic information tion. 

while an application is failing. To this end, a diagnostic As stated above, the system module provides the present 

panel is preferably available from the Windows Task Tray at invention with a "socket" paradigm. Using sockets, there is 

all times and is accessible while an application is failing for a guarantee that data is transmitted to the destination appli- 

real-time diagnostic analysis. Without shutting down the 55 cation only once. This is true because a socket is a conver- 

user application, a diagnostic panel in a window can report sation between two applications and not two wireless 

all of the information about problems with the connectivity devices or two middleware APIs. 

whether or not the application was developed to report this The sockets used by the present invention are optimized 
information. This eliminates the old ways of diagnostics, for wireless transmissions, and, preferably, the high- 
such as making the user drop down to the DOS prompt, 60 overhead expensive TCP/IP protocol is not used over the air. 
examine and potentially change an INI file, grab a log file, Instead, each packet is disassembled, optimized for a wire- 
print it and fax it, or upload the file to a customer service less transmission, and recreated on the other side. In 
representative to determine the nature of the problem. This particular, different types of information are preferably 
of course also assumes that the log could be successfully provided in a single packet. Specifically, the packet prefer- 
created by the application and saved to disk. The diagnostics 65 ably includes both user data and transport confirmation data, 
of the system module are "live" and any problems may The preferred packet contains at least six separate categories 
possibly be fixed without the user even exiting his or her of information, including (1) destination address, (2) source 
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address, (3) user data, (4) transport confirmation, (5) deliv- 
ery notification, and (6) performance and load information. 
All or some of these segment types could be combined 
within a single packet. 

The transmission of a packet could be triggered by one of 
the following conditions: the presence of data; a request for 
socket connection; the need to generate a confirmation; or 
the notification of delivery sent when an application 
retrieves the data from the wireless control program sub- 
system. 

The protocol optimizes the number of packets sent. 
Namely, after the last segment, which makes up a message 
is received by the program subsystem, there is the need to 
generate a transport level confirmation. The system module 
will fire events to the application notifying it of the message 
that is pending retrieval by the application. The system 
module expects the application to retrieve this data, and the 
act of retrieving this data will cause the system module to 
generate a delivery notification. Before sending this delivery 
notification, the system module will preferably wait a small 
amount of time for outgoing data. This delay accounts for 
the presumption that the application uses a higher level 
protocol and will respond to the newly-retrieved message. 
By following these rules, the system module attempts to 
fully utilize the outgoing packet by including the transport 
confirmation, message delivery notification and the outgoing 
data within the same outgoing packet. 

Destination address information provides the destination 
of the packet. Source address information represents the 
sender or source and can be used for return communications 
once a connection is established. User data represents the 
actual data to be sent (e.g., an e-mail message). Transport 
confirmation data is used to indicate that data was sent to the 
computer. Delivery notification information is used by sys- 
tem module to notify the application that data was success- 
fully sent to the destination application. 

Performance information is used to monitor performance 
show fast the modem can send/receive and load information 
is used to monitor the strain or load on the modem, such as 
the amount of data currently being received by the modem 
from other sources. Thus, if too much data is being sent to 
a modem, the modem can overflow. However, with the 
transmission of packets in accordance with the present 
invention, modem performance data can be sent along with 
the data in the same packet such that the system can slow 
down or speed up data receipt based on the performance data 
in the packets being sent. Not only can speed or performance 
be monitored and controlled by the packet transmissions, but 
load can be monitored and controlled as well For example, 
if a modem is receiving information from three sources, one 
of which is sending too much data, the receiving modem can 
send back information to the modem sending too much data 
and request that it reduce the amount of data being sent in 
the transmissions. 

In another aspect of the wireless transmission protocols of 
the present invention, a "sleep" or wait feature is provided 
to allow for combining or appending small packets which 
are generally close in time which would have normally been 
sent as separate packets. This saves wireless transmission 
costs since it normally costs more to send two small separate 
packet transmissions, one at a time, rather than one com- 
bined packet which would take the same amount of time to 
send as the first small, separate packet. 

Thus, the overhead of keeping the socket alive, key to 
every TCP/IP stack, is maintained in a wirelessly optimized 
fashion and traffic over the air is kept to a minimum thus 
keeping costs and transmission times down. 
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In order for a message to be considered complete, it must 
be accepted by the destination application. Referring to FIG. 
7, middleware considers a message complete when the 
destination middleware API 172 receives the transmission 

5 regardless of whether the application ever receives it. 
Middleware can often retransmit entire messages and user 
applications must therefore handle this situation. The 
present invention can confirm that data has been transmitted 
by making application-to-application confirmations, notify - 
ing that data was delivered to the end application 174, and 
guaranteeing that the user received only one copy of data. 
Middleware cannot guarantee that data was received by an 
application once, twice or even at all, as middleware uses 
middleware-to-middleware confirmations, not application- 
to- application confirmations, 

15 By utilizing objects to establish a connection rather than 
individual transmissions, re-transmissions of data, in those 
rare situations when they must be, are minimized. For 
instance, if a file is 95% transmitted and the user goes out of 
coverage for 2 hours, the present invention is able to respond 

20 gracefully and the open connection can be utilized to 
re-transmit portions of messages. When the user comes back 
into coverage, the socket is still alive and the unfinished 
message will finish by only transmitting the remaining 
unsent data. The socket on the other end will hold the portion 

25 of the unfinished message until the socket is consciously 
destroyed. In a middleware environment, the transmission 
will time-out and the portion of the message which was sent 
is discarded thus wasting money. In order to gain this same 
type of result using middleware, messages must be kept very 

30 small (packet-sized) and every application would have to 
manage the breaking up and reassembling of the messages. 

The system module of the present invention preferably 
includes built-in data compression for messages, which can 
help keep transmission costs down. Standard TCP/IP imple- 

35 mentations do not use compression which is optimized for 
wireless transmissions if they use compression at all. 
Therefore, even standard applications that run with the 
present invention, such as web browsers and FTP software 
using the Winsock 2 driver from DMD, will benefit from 

40 compression. 

Varying types of data compression can be used depending 
on the nature of data being sent. The system module can 
utilize a variety of compression schemes such a PKZip and 
other proprietary compression algorithms. The system mod- 

45 ule takes the structure of the data into consideration and uses 
the most optimal compression algorithm. Most conventional 
compression algorithms are comprised of two components, 
the compressed data and a table which hold information 
necessary to de -compress the data. The system module's 

so proprietary compression algorithms do not need to send the 
table portion over the air because this table is part of system 
module. This scheme saves precious wireless bandwidth and 
allow for efficient compression of even very small blocks of 
data. 

55 The system module of the present invention preferably 
uses the Crypto API built into the Microsoft operating 
systems to provide built-in encryption to applications. By 
using this infrastructure, end-users can choose to use the 
Microsoft-provided encryption method, any number of third 

60 party encryption methods, or even expand the present inven- 
tion to use a custom defined encryption scheme. 

The system module further takes into consideration the 
local characteristics of the wireless device, such as battery 
strength, RSSI etc., as well as the load on remote devices 

65 such as number of sockets, RSSI etc. Network conditions 
such as out of coverage and registration status are also taken 
into account. 
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The system module of the present invention also avoids 
some of the other pitfalls of using a standard wireless 
network approach such as broadcasting. Namely, with 
broadcasting using a standard network driver, the network- 
ing protocol used assumes there is a high bandwidth avail- 
able and will broadcast information between the computers, 
attempt to re -connect drive mappings, attempt to connect to 
printers, etc. There is no way to turn many of these features 
off. With the system module of present invention, broad- 
casting to each of the attached devices is eliminated as 
broadcasting is costly in a wireless network in which over- 
the-air transmission time is charged for. 

The system module preferably is programmed with the 
ability to wirelessly update itself. Namely, as new versions 
of the wireless control program subsystem are made avail- 
able with features that are important to an enterprise, such 
features can be added by generating an update request to a 
server which can wirelessly transmit software and remotely 
install applications. The system module also supports the 
ability to wirelessly transmit flash updates and remotely 
re-flash the BIOS on the wireless device for those wireless 
devices and platform environments which support this fea- 
ture. 

B. The Shell Extension Module 

The shell extension module 31 of the wireless control 
program subsystem extends the Windows OS by extending 
the Windows Shell provided with the Windows operating 
system. Thus, with the shell extension module, the present 
invention is truly integrated into Windows 32-bit operating 
systems (Windows NT 4.0+ , 95, 98 CE 2.0+, etc.). 

The Windows Shell is the user interface of Windows 
which provides the desktop, windows, icons and other GUI 
elements to the user. In the present invention, the shell 
extension module provides programming or COM objects 
usable by Windows to provide additions to the Windows 
Desktop, Windows Explorer and Control Panel. The COM 
objects are objects known by the system and are used to 
create menus, windows, columns in windows, etc. The COM 
objects provided by the shell extension module include: 
IEnumlDList, lExtractlcon, IPersistFolder, IContextMemi, 
IShellExtlnit, IShellFolder, IShellView and IShellPropShee- 
tExt. Development of such shell extensions is within the 
skill of the ordinary Windows programmer and information 
relating to the development of such COM objects can be 
found, for example, in Microsoft Systems Journal, Vol. 13, 
No, 8, August 1998 issue, which is incorporated herein by 
reference. 

As shown in FIG. 8, with the programming objects 
provided by the shell extension module, the Windows Shell 
is extended by adding to Control Panel window 180 a 
Wireless Networking folder 182 and a Wireless Devices 
folder 184. These folders are accessible via the Control 
Panel, Windows Task Tray, and Windows Explorer (see FIG. 
9). Context or pop-up menus such as menu 190 as typically 
provided in Windows are also available on all objects via 
right-clicking the mouse. 

Automated, user-friendly "wizard" programs are prefer- 
ably used by the present invention to provide easy ways to 
configure and re-configure wireless devices and networks. 
For instance, as shown in FIG. 10, wireless devices can be 
easily added via Add Wireless Device Wizard (see window 
200), new domains can be added via New Domain Wizard 
(see window 21 of FIG. 11) and new hosts can be added by 
New Host Wizard (see Window 220 of FIG. 12). Because of 
these wizards, there are no INI (configuration) files to edit 
and configuration is done completely through the Windows 
GUI via well-defined programming interfaces. 
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The wireless control program subsystem of the present 
invention preferably starts automatically when a wireless 
connection is attempted. Once running, as shown in FIG. 13, 
status information is accessible from the Windows Task Tray 
230 by positioning the pointer arrow 232 over icon 234 to 
display an informational window 238. Furthermore, the 
configuration panel is also available from the Windows Task 
Tray by right-clicking on the icon 234. 

Once the wireless control program subsystem is installed, 
a start-up icon preferably appears on the desktop of the 
computer. For example, as shown in FIG. 14, icon 240 
entitled Wireless Networking is provided on desktop 242 in 
a Windows CE operating system. Property Sheets, such as 
Wireless Networking Properties window 250 shown in FIG. 
15, are also preferably available for all objects as well. 

As stated above, there are no INI files used to configure 
with the wireless control program subsystem. Instead, the 
accepted standard by Microsoft and many third party appli- 
cations is to use the information in the Windows Registry (a 
database used to store configuration information) to make 
intelligent decisions. An example of the use of this Registry 
information is back-up software, and server management 
software such as SMS (Microsoft's System Management 
Server which provides tools to assist in managing PC's 
connected to a LAN). By storing all information in the 
Registry, the wireless control program subsystem's configu- 
ration can be managed and backed up by these utilities, a 
feature which is much more difficult using an INI file, if 
possible at all. 

The present invention also provides status windows to 
show names which mean something to the user (and not 
what the system decides it should be named) much in the 
same way that a user may name a printer whatever he or she 
chooses. Likewise, friendly names for wireless hosts are 
available such that the end-user can assign names to remote 
servers and peers which make sense to the end-user of the 
system, instead of having the application developer and/or 
administrator define some name that must be appropriate for 
the end-user. 

As stated above, the system module of the present inven- 
tion utilizes an architecture which abstracts the wireless 
devices into objects which can be represented on the screen 
as screen objects such as Add Device object 262, Internet 
Connection object 264, My PIA Card object 266 and My 
Pocket Plus object 268 (FIG. 16). These objects have 
properties in a similar metaphor as printer objects in Win- 
dows, Namely, in the same way that printers installed on the 
computer have properties, wireless devices also have prop- 
erties. Windows supports an architecture which will allow it 
to support all future as well as legacy printers. In the same 
way, the present invention's architecture provides extensi- 
bility for all wireless devices in the market today and 
tomorrow. Just as any application written today is protected 
against new printers, applications will be ready for new 
wireless devices and networks and protocols in the future. 

With the present invention, wireless devices are prefer- 
ably provided with two types of properties: static properties 
and dynamic properties. Static properties are those in which 
the value is determined without device activation (i.e., 
communication port, device name, etc.) while dynamic 
properties are those in which the value can only be obtained 
from device when it is activated (i.e., IP address of a modem, 
the base-station to which the user is communicating, etc.) 
Static and dynamic properties of the wireless devices can be 
viewed and/or edited by means of standard property pages 
directly by system means (i.e., Windows Explorer). Both the 
dynamic and static properties can be read-only or read-write, 
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depending on property and the device. For instance, in the 
case of the Mobitex network, the dynamic property MAN 
(Mobitex Access Number) for a radio modem (a/k/a 
"Mobidem") is read-only, but in the case of CDPD (Cellular 
Digital Packet Data), the dynamic property IP Address for a 
Sierra Wireless modem is read-write, while its EID 
(Equipment Identifier) is read-only. 

The present invention uses a new way to define new name 
spaces (i.e., addressing schemes) for additional socket lay- 
ers. For instance, the name "Wireless Networking" 270 
shown in FIG. 17 is actually the Dynamic Name Space 
(DNS) of the wireless control program subsystem itself. As 
shown in FIG. 18, the name DMD 280 is shown as the 
current host that includes two servers, Mail Server 282 and 
App Server 284. The servers' respective IP addresses 283 
and 285 are also shown. Additional hosts can be added via 
launching the Add Host icon 286. 

The present invention also provides a built-in address 
book in which the user can send information to predefined 
names such as "Andrew" instead of the numeric IP 
addresses, MAN numbers, or whatever the native addressing 
is for the particular network in use. Further, well-known 
hosts in the address book can be designated to use a 
particular wireless device. This can also be changed at any 
point without the application having to change. The end-user 
can therefore switch networks without even touching the 
source code of the application. 

Addressing can also allow multiple wireless devices from 
a particular network to be connected to a single machine and 
the present invention can choose the most appropriate device 
for given types of communications, such as "hot backup" 
(i.e., if a link goes down the system automatically switched 
to a different device) or communications via least -cost 
routing by selecting devices which will result in the lowest 
communications costs. 

Addressing in accordance with the present invention 
further allows inter-networking and sub-networking. For 
instance, using the filtering features preferably included in 
the present invention, administrators can limit the hosts to 
which a particular client can send. This can keep costs down 
and prevent transmissions sent in error. 

The present invention's wireless networking features pro- 
vide numerous routing capabilities allowing disparate net- 
works to communicate, devices to be shared across a LAN, 
multiple devices on the same machine, etc., all without 
changing programming but simply using the GUI to modify 
the properties of the wireless control program subsystem. 

With the present invention, mobile users can always 
create sockets to one another regardless of what wireless 
device is being used on any particular day since the address 
book is maintained on the router. In middleware solutions, 
each machine had to maintain a list of remote addresses and 
friendly names for each of them. If a change was made 
because a particular device was broken or a user was 
assigned to a different truck, this information has to be 
propagated wirelessly to each machine, a very costly 
requirement. This unnecessary requirement of middleware 
has been eliminated by the present invention by preferably 
routing all traffic through a central server. 

Referring to FIG. 19 an example is shown of the present 
invention's routing capabilities. Here, Client 1 at box 290 
wants to create a connection with Client 2 at box 292. Client 
1 and Client 2 both only have in their Wireless Networking 
properties set up an address for a router 295. Client 1 can 
create a connection to Client 2 by allowing the wireless 
control program subsystem to forward packets to the server 
294 acting as a router machine (in this example, IP address 
5.2.3.2) where the address is resolved and forwarded again 
to Client 2. 
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The system and shell extension modules of the present 
invention provide a naming scheme hereinafter called 
"Dynamic Name Space" or DNS. DNS is analogous to the 
way the Internet URL names works today. Namely, if a user 

5 goes to a browser and enters the address http://38.216. 39. 2, 
the browser will connect to the Dynamic Mobile Data web 
site. However, it is much easier to remember the address 
"www.dynamicmobiledata.com", especially considering 
that Dynamic Mobile Data may change ISP's in the future 

10 and the numeric IP address may change. The Internet may 
have lost attractiveness and would never have gotten as 
popular if users had to enter a port number and an IP address 
into a browser. Instead, you simply enter a protocol (or use 
the default hup:) and enter a name (such as 

is www.dynamicmobiledata.com). 

Likewise, with the present invention, a user can send 
wireless information to users using domains, names, and 
services. Therefore, if a user changes wireless devices 
and/or networks, the socket can still be created as the 

20 destination will still be found. Implementing common ser- 
vices will mean that an application can connect to a well- 
defined service on any of a number of hosts in the same way 
a browser connects to a WWW (World Wide Web) service 
on one of many well known hosts. 

25 The present invention allows many machines to share a 
common Dynamic Name Space. This is done using the 
advanced routing capabilities provided to the user and/or 
application. Namely, the system and shell modules can be 
configured to forward all packets through a default device 

30 regardless of the destination host name. The address is 
resolved when the packet reaches the default router so 
defined. In turn, the remote router will forward the packet on 
to the destination system and a socket will be established for 
these remote machines through this router. 

35 C. The Programming Module 

As explained above, the programming module of the 
present invention extends the Windows OS by extending 
Winsock by providing objects through the C++ class library 
to programmers. With such objects, programmers can 

40 readily use this module to build applications and create 
virtual connections to other applications across one or more 
wireless networks and/or wired networks. 

With the programming module, application can be written 
such that messages are guaranteed to be delivered in order. 

45 According to the Winsock specification, unless you specify 
an "out of band" message, messages must be delivered in 
order. This makes user coding much easier. Thus, with the 
present invention, messages will always appear on the 
opposite side in the order in which they were sent. Rather 

50 than creating a large message with all of the information and 
then writing complex parsing code on the opposite end, a 
programmer can send each piece of information in a separate 
message. The receiving application does not have to parse or 
break apart the incoming messages, as the application will 

55 get a distinct "Message Received" event for each message 
and can handle each individually. Alternatively, an applica- 
tion developer can send a large message and allow the an 
application to send it all as once large message and have a 
single Message Received event for the message. It is the 

60 choice of the application developer. 

With the present invention, programmers have the free- 
dom to use whatever programming paradigm they choose 
and can mix and match these paradigms within applications 
if different portions of the application have different require- 

65 ments. Examples of how each paradigm is implemented are 
peer-to-peer, client-server, server-to-client (force 
dispatched), three-tiered and browser. 
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In peer-to-peer programming, one application can create bridging capability. Any socket can cross as many network 

a socket with another application on another machine. boundaries as necessary. For instance, a socket could be 

Bother peer machines would be listening for connections created in CDPD, go into RAM, and from there go into a 

and can create and accept sockets. Once sockets are created, regular LAN or WAN. Thus, one machine can simulta- 

both sides can send messages across the socket. This para- 5 neously send data over many wireless networks providing an 

digm is ideal for clients who are on-line all of the time, for even better chance at getting close to 100% coverage, 

installations which have no server, or installations which Further, an application can be defined to use the best 

have a great deal of peer-to-peer messaging requirements. network and least expensive network on the fly by having 

For client-server programming, once a connection to a more than one network and more than one device on the 

remote application has been made, both sides can send at machine. For example, an application can be written to use 

will. This is key to a client and server model. No longer will a wireless LAN connection or infra-red communications 

applications need to employ a "try and wait" paradigm, as when in local coverage, and when the mobile unit leaves the 

servers can simply listen for client connections and send local coverage, to automatically switch to a public network 

only when those client connections exist. This paradigm is using a wide area radio. 

similar to a mail client paradigm where mail servers only Through application routing provided by the present 

forward mail to a user when the client has logged in. If mail 15 invention, unlimited applications can be connected simulta- 

servers used the middleware paradigm, they would attempt neously. The system module of the present invention thus 

to send mail to a client every time a new message was acts as a marshal between the processes and allow all 

received and would keep sending the message until the applications to use the full capabilities of the system. This 

client eventually came on line and could receive it. Mail includes all wireless devices, all diagnostic reporting, etc. 

servers would become very quickly bogged down in this 20 User applications can also be deployed alongside system 

paradigm. The same is true for a wireless application. There services delivered by third parties, 

is no need to send a message to a user who is not there. Using The present invention allows programmers to have the 

a connection-based paradigm, the chance of sending a ability to re-route inbound packets from one wireless device 

message to a client who is not ready to receive a message can to another wireless device. Utilizing this feature, a socket, 

be significantly reduced. 25 for example, can be created from a Mobitex device to a 

With server to client (forced dispatch) programming, a CDPD device via a single server which is configured with 

server can create a socket to a client just as a client can create devices for both protocols. 

a socket to a server. In this instance, the server would be Socket routing, through the system module, is also pro- 

using the peer-to-peer model alongside the client-server vided by the present invention, which is actually network 

model. 30 routing split out to yield significant advantages. Socket 

For three -tie red programming, this approach would be an routing allows sockets to be sent from one wireless network 

extension of the client-server approach. A server application to another disparate wireless network. For instance, through 

which receives a socket from a client can pass data off to an socket routing, a socket can be connected to a disjoint 

"agent" which can perform a task such as a host transaction network through a central server. In other words, all users of 

or a web-based query. Then, the information can be passed 35 one network can be given access to all users of another 

back to the application across the socket. network via a central server and all of these users can treat 

Finally, for browser programming, the present invention's the remote device as their own. 
Winsock 2 driver can be used to deploy HTML and Java- The present invention can also be extended to a LAN- 
based applications wirelessly. based device. Thus, an application can be built which has 

The programming module of the present invention 40 only one wireless (really wired) device attached to it such as 

enables programmers to also guarantee that transmissions a direct LAN connection. A single box on the LAN can then 

have been accepted by the receiving application; not just the have a wireless modem attached to it and, using the present 

receiving modem. In middleware solutions, modem -to- invention's wireless network routing features, all LAN users 

modem confirmations are made. Therefore, if a remote can create sockets using the same wireless device, 

modem is on and connected, but a user application is not 45 Any and all of the components built by software devel- 

ready, and/or the computer is not connected to the modem, opers can be used simultaneously in the same application, 

the sending side will assume a successful send when in fact, This means that you can have one application talking 

this is not the case. The application may never see this Winsock, ODBC and ActiveX, all together without any 

message. With the present invention, the application must problems. By contrast, in stacked middleware approaches, 

perform an acceptance of the packet. Once this acceptance 50 once a developer picks a target API, he is restricted to that 

has been made, the socket is used to send a confirmation level and cannot ask questions to stacks below or above it, 

back. The sending application can now, with confidence, flag The present invention gives the user the freedom to ask 

the message as sent successfully. questions on any level at any time, and to use multiple levels 

With the present invention, applications be written to use at once. For example, one application can user higher level 

one or more wireless devices, and wireless devices can be 55 ODBC commands which have no concept of signal strength 

used by more than one application through device routing. and at the same time have another socket using ActiveX 

This feature allows a user to have an application serving reacting to changes in signal strength. Using middleware, 

connections from different wireless networks and/or wire- the developer who chose to use ODBC would be restricted 

less devices. Applications can be connected through sockets to use only the functions which ODBC provides, 

to more than one application at the same time and those 60 Prior to the decision of which wireless infrastructure is to 

applications can exist on one or more remote machines. be deployed, all application development can nevertheless 

Applications can also be communicating over one or many proceed using the with the application configured to use a 

wireless networks simultaneously. Sockets can be created LAN (Local Area Network). This is because using the 

across different wireless networks via the present invention present invention, there is no practical difference between 

is configured as a network router. 65 wireless and wired networks. Applications can be designed, 

The present invention supports multiple wireless net- developed, and tested in LAN environment and then 

works at the same time (like CDPD and Mobitex) providing deployed in a wireless network environment. 
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Likewise, an application written for a mobile device using 
a wireless network can be brought back to a docking station 
and operate over a wired network (and even over the 
Internet) without requiring code changes, or underlying API 
and DLL replacement/renaming, etc., by simply adding a 
wired Host to the Wireless Networking Folder and the 
application will have all of the knowledge to communicate 
over the wired network. 
D. The Industry Standard Interface Module 

The industry standard interface module exposes to the 
programmer standard interfaces in which to program, and 
allows development of industry-standard programs using 
ActiveX controls, Winsock and ODBC. Thus, this module of 
the present invention was designed to accommodate 
ActiveX, Microsoft's components and technologies for cre- 
ating controls that can be downloaded and executed by a 
web browser and have full access to the Windows operating 
system. Thus, the present invention uses COM (Component 
Object Model) objects on which ActiveX is based and 
provides Microsoft Windows shell extensions to configure 
its options, a feature only available through the COM 
specification. Likewise, the present invention also accom- 
modates programming using Winsock and ODBC. 

The present invention is also capable of exposing many 
interfaces through COM in the future. By using advanced 
features of Microsoft's Active Template Library (ATL), the 
present invention is ready for DCOM (Distributed COM), 
giving programmers the ability to deploy ActiveX controls 
remotely. 

The present invention preferably uses MobileX™, an 
ActiveX-based interface offered by DMD, as its first inter- 
face. MobileX™ is a connection-based message control 
which models very closely the core functionality of the 
present invention exposed as an ActiveX interface. ActiveX 
is implemented using Microsoft's ATL and DCOM is built 
to be used remotely. As MobileX™ is built in this manner, 
it provides an ability to have one server directly connected 
to Mobitex and/or CDPD and offers multiple application 
instances in the same LAN and/or WAN. 

MobileX™ thus provides a core, "down and dirty" 
wireless-aware Winsock programming tool for the user and 
provides an easy way for programmers to use a program- 
ming language which supports ActiveX controls (e.g., 
Visual Basic, C+ + , Delphi, Internet Explorer, 
PowerBuilder). Thus, no knowledge of a C-based API is 
even needed. All properties are exposed through a type 
library and a dual-interface is exposed, making it very 
efficient in environments like Visual C++. Full MFC Wizard 
support is also provided (a wizard API provided by 
Microsoft) 

The present invention does not use straight TCP/IP pro- 
tocol over networks like CDPD for various reasons, TCP/IP 
is inherently a heavy protocol and is not suited very well for 
wireless applications. Most IP stacks today use a dial-up 
networking approach, and standard IP stacks and standard 
TCP/IP applications cannot react properly to the challenges 
in wireless computing. 

Because developers have invested large amounts of effort 
in developing applications on LANs which employ certain 
standard higher TCP/IP architectures such as POP, SMTP, 
etc., the present invention also includes a more wireless- 
aware TCP/IP transport protocol in order to help users 
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leverage this code where it makes sense. Therefore, some 
less critical messages can be sent via standard means, and 
those messages over which more control is needed, special- 
ized wireless routines may be built. 

S The present invention exposes a standard Winsock 2 
driver and thus any programs previously written to Winsock 
2 can be used by the present invention. Also, the present 
invention makes the address book as a name space extension 
to Winsock 2. Thus, standard Internet and/or TCP-IP appli- 

10 cations can be run with the software of the present invention 
and the adds the benefit of simultaneously working with 
applications which are more wireless-aware. 

In the same respect as the Winsock 2 Driver, the present 

15 invention preferably includes a wireless database access 
infrastructure, and preferably MobileQuery™ offered by 
DMD. MobileQuery™ allows existing applications to run 
against remote databases by exposing a Level 3 Compliant 
ODBC Driver for Windows 95 and Windows NT. Mobile- 

20 Query™ intercepts calls made to the driver, transmits them 
wirelessly, and executes them on the server against any 
Level 1, Level 2, or Level 3 ODBC driver. Results, error 
messages, etc. are then passed back to the client. By employ- 
ing this architecture, the wireless control program subsystem 

25 can wirelessly enable any ODBC-compliant database. 

The present invention may also include SNMP (Simple 
Network Management Protocol) hooks so that users will be 
able to monitor remote wireless devices. Using the address- 
ing scheme of the present invention, a wireless network 

30 administrator is capable of defining a subset of the devices 
to be monitored by any available criteria. Also, data which 
is received can be populated up into a standard SNMP 
viewer such as Open View. 
E. Applications 

With the present invention, end users can run applications 
written for communicating with and managing wireless 
devices. The present invention gives mobile users an ability 
to run standard software such as FTP (file transfer protocol) 

40 software and browsers using the industry standard interface 
methods described above. 

Third-party applets can be run and provide a great deal of 
functionality to the mobile system so that these functions do 
not have to be re -written each time. The applets can be 

45 automatically started by the present invention when an 
incoming socket requests it. 

The present invention has the ability to allow the user to 
configure the software to provide notifications of wireless 
events in a number of ways including pop-up boxes, e-mail, 

50 log-files, etc. This allows a user to have better customiz- 
ability. For example, if an application is not defined to notify 
the user when he is in a fringe area, the user does not need 
to ask the developer for a change to the application, he can 
tell the Notification Manager to display a pop-up box and 

55 play a WAV file when he goes below a certain level. 

The present invention also has the ability to launch known 
applications when pending sockets arrive for the application. 
This means that remote applications which are used rarely 

60 can be automatically started when requested by a remote 
server or remote mobile device and instantly become avail- 
able. Also, applications by third-party vendors which are 
wirelessly aware can run along side any other wireless 
application based on the present invention. Finally, user 

65 applications which have been custom deigned and built for 
a particular mobile user will gain all of the benefits discussed 
above. 
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III. Software Installation 

The preferred requirements to run the wireless control 
program subsystem of the present invention include a com- 
puter running Windows 95 (service pack 1 or higher is 
preferred) or Windows NT 4.0 (service pack 3 or higher is 
preferred). Hardware requirements include a PC or 
PC-compatible computer (and preferably at least an Intel 
Pentium processor), 16 MB of RAM, at least 1 MB of free 
hard disk space, one or more wireless communications 
devices and an active subscription to a wireless network 
provider. Winsock 2 is also necessary for Windows 95 
installations. 

The wireless control program subsystem can be loaded 
via software on the PC through standard installation tech- 
niques such as by floppy disks 21 or CD-ROM 22 (FIG. 2) 
which will guide the user to follow installation prompts on 
the screen. During installation, as shown for instance in FIG. 
20 which shown an initial installation screen 300, certain 
options such as components 302 can be selected by clicking 
the mouse once on checkbox of the desired option. 

During the installation procedure, a "Local Host Name" 
must be entered as shown on screen 310 of FIG. 21 which 
will be used to identify the user's local host. If the Host 
Name field is left blank, the user's PC name will be used as 
the default for the local host name. 

After installation, the user is provided access to a new 
desktop icon 320 labeled Wireless Networking (FIG. 22). To 
start the program, the user can simply right-click the Wire- 
less Networking icon 320 and select Start from the pop-up 
menu 322 (FIG. 23). After starting, the user will see icon 324 
in the system task tray 326 (FIG. 24), indicating that the 
wireless control program subsystem has been started. Also, 
placing the mouse over this icon will display in box 328 the 
current status of some of program's connection statistics 
(FIG. 24). 

To exit or quit, the user can right-click the icon within the 
system task status bar and then select Close from pop-up 
menu 330 (FIG. 25). The wireless control program sub- 
system is designed to terminate all currently active socket 
connections before stopping, and the user will be given the 
opportunity to abort the exit process in the event that Close 
was selected accidentally. 

Preferably, installation macros or "wizards" are provided 
as means through which the user can configure the operating 
environment, which consists of wireless Networking 
Properties, Devices, Hosts and Domains. To this end, as 
shown in FIG. 26, the Windows Explorer Shell 340 is 
extended with a Wireless Networking folder 342 and a 
Wireless Devices folder 344, which are accessible via the 
Control Panel 346 or the Windows Shell. Context Menus are 
also available on all objects. 

The Device Wizard (FIG. 27) allows the user to easily 
configure a device for use with the program. The Device 
Wizard is comprised of three set-up screens-the Identity, 
Communications, and General Properties screens. To add a 
Device, the user can select Add Device from either the 
Control Panel or the Add Device label 350 from the Win- 
dows Explorer by selecting Wireless Devices. The user can 
then choose the desired device from the list 352 of available 
wireless device drivers in the Identity screen 354. 

As shown in FIG. 28, the first screen within the device 
wizard is the Device Identity screen 364. Here, the user 
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provides a name for the new device configuration and then 
sets the Device Startup Mode (FIG. 27), by selecting either 
the "automatic" radio button 366 or the "on demand" radio 
button 368. "Automatic" indicates that the wireless control 
5 program subsystem will attempt to initialize the device when 
the wireless control program subsystem is started while "on 
demand" means that the wireless control program subsystem 
will not initialize the device until an application attempts to 
use it. 

10 The second screen shown holds communication-related 
parameters and will differ depending on the device type. The 
different configurations include CDPD and Mobitex Mobile 
Configurations, Mobitex X.25 Direct Configurations, Mobi- 

i5 tex Internet Direct Configurations and CDPD or LAN/WAN 
Direct Configurations. 

Referring to FIG. 29, to configure a PCMCIA, integrated, 
or external Mobitex or CDPD device, the following steps are 
followed. First, the user selects the communication port 

20 from drop-down list 372 in window 370 to associate with 
this configuration. Next, if applicable, the user selects the 
line speed from drop-down window 374 at which the 
wireless control program subsystem should connect to the 
device. 

25 Referring to FIG. 30, for configuring a Mobitex X.25 
Direct configuration, the user enters the X.25 Eicon card 
Port ID at location 382 in window 380 that was previously 
entered as part of the Eicon card installation. Next, the user 
enters the remote X.25 address at location 384, the Local 

30 X.25 Address at location 386 and the Mobitex access 
number associated with this configuration at location 388. 

Referring to FIG. 31, for configuring a Mobitex Internet 
Direct configuration, the user enters the TCP/IP Port ID at 
location 392 at window 390, the IP Address at location 394, 

35 and the Mobitex access number associated with this con- 
figuration at location 396. 

Finally, referring to FIG. 32, for configuring a CDPD or 
LANAVAN Direct configuration, a screen 400 is presented 

40 to the user to enter the port ID at location 402 to associate 
with such connection. In most cases the default value of 
43690 is sufficient. 

The third and final screen holds General properties related 
to the device and will differ depending on the device type. 

45 For Mobitex, as shown in FIG. 33, the user can indicate at 
screen 410 whether the device will use a remote router at 
check box 412. If this option is selected, the user must also 
provide the network address of the remote router at location 
414. The user must also indicate if the device is to be used 

50 as the default device at check box 416. The default assign- 
ment indicates that this device will be used for all socket 
connections that do not specify a domain as part of their 
destination address. 

For CDPD, as shown in FIG. 34, the user can indicate at 

55 window 420 whether the device will use a remote router at 
check box 422. If this option is selected, the user must also 
provide the network address at location 424 and port ID of 
the remote router at location 426, The user must also indicate 

60 if the device is to be used as the default device at check box 
428. The default assignment indicates that this device will be 
used for all socket connections that do not specify a domain 
as part of their destination address. 
As shown in FIG. 35, once the user has added a new 

65 device, e.g., "Sample Device" label 432 shown in the Wire- 
less Devices window 430, the device is immediately usable 
by program. 
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The present invention also allow the user to easily modify 
an existing device. Namely, to modify an existing device, the 
user first selects its properties by right-clicking on the 
device, such as SampleDevice 432 specified in the Wireless 
Devices window 350 shown in FIG. 36. The user then 
selects "Properties" 434 to then display a Properties window 
440 as shown in FIG. 37 and is then free to modify any of 
the device's configurable properties under each tab such as 
tab 442 for General properties, tab 444 for Connection 
properties and tab 446 for Routing properties. 

To remove an existing device, as shown in FIG. 38, the 
user can simply select the device from window 450, such as 
selecting SampleDevice 452 by right-clicking with the 
mouse, and selecting Delete command 454 to perform a 
delete operation just as with deleting a file. 

A Domain Wizard is also provided to the user. A Domain 
is defined as a group of Hosts within a particular wireless 
network, and a Domain name is the name that is given to this 
group of Hosts. As shown in FIG. 39, to add a Domain, from 
either the Desktop or Explorer, the user can double-click the 
wireless networking Icon 460 or right-click the wireless 
networking icon and select the Open command 462. 

Referring to FIG. 40, the user then presented with the 
Wireless Networking screen 470 and double-clicks on the 
"Add Domain" item 472 to start the Domain Wizard. The 
New Domain Wizard screen 480 (FIG. 41) is then presented. 
This screen allows the user to specify attributes for the new 
domain. First, the user enters a domain name at location 482 
to identify the domain. Then, the user selects a network type 
from the drop -down list 484 to associate with this domain 
(each domain is bound to a single particular network type). 
Finally, the user assigns a global network identifier to the 
domain at location 486 (in most cases the default value will 
be sufficient) and clicks Finish. As shown in window 490 
(FIG. 42), the new domain (here "SampleDomain" 492) will 
then be displayed in the Wireless Networking view. 

To modify an existing Domain, the user selects its prop- 
erties as was done in the device wizard, and then changes its 
parameters appropriately. To remove an existing Domain, 
the user simply selects the Domain, and then performs a 
delete operation just as with deleting a file. 

A Host Wizard is provided to add a Host. A Host is a name 
that is used to associate a user or machine within a particular 
Domain. Referring now to FIG. 43, to associate a host with 
a previously-specified domain, the user double-clicks on the 
Domain in the Wireless Networking window that the user 
wants to add to (in this case SampleDomain label 502) or 
simply right-clicks the Domain and selects the Open func- 
tion 504. This action will then display the list of hosts 
associated with the selected Domain, if any. The Host 
Wizard will then appear (see FIG. 44) with window 510 and 
the user double -clicks the "Add Host" icon 512 to start the 
Host Wizard. 

The first host wizard screen will differ depending on the 
network type that is specified when creating the domain. As 
Domains are associated with specific networks, any Hosts 
assigned to these Domains will posses network specific 
attributes such as network address formats. 

For CDPD (FIG. 45), the user first specifies a name such 
as "SampleHost" in location 522 in window 520 to associate 
with this Host. Next, the user enters the IP access number of 
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the host in location 524. For Mobitex, (FIG. 46), the user 
first specifies a name as before such as "SampleHost" in 
location 532 in window 530 to associate with this host. Next, 
the user enters the Mobitex access number of the host in 

5 location 534. 

The next and final screen (FIG. 47) presents a generic 
window 540 and indicates whether or not this host will act 
as a router at checkbox 542. If the host is specified as a 

10 router, the user must also select a device at location 544 and 
associate port id at location 546. The icon SampleHost 552 
in window 550 is then shown with the Mobitex Access 
Number in Window 550. 

To modify an existing Host, the user can select its 

15 properties (as was done in the Device wizard example 
above) and then change its parameters appropriately. To 
remove an existing Domain, the user can simply select it, 
and then perform a delete operation just as with deleting a 

20 file - 

To modify the Local Host, the user can right-click the 
Wireless Networking icon from the desktop and select the 
Properties command from the pop-up menu. The user can 
then re-configure the existing properties from the Wireless 

25 Networking Properties screen 560 (FIG. 49). The Host 
Name in the name field 562 is a name that identifies the 
user's machine. The time field 564 indicates the duration 
which the Wireless control program subsystem will wait 

30 before closing the connection in the event that network 
coverage is lost. The default time set is preferably one hour. 

The wireless control program subsystem also provides 
users with configuration screens (administered primarily by 
the Device, Host and Domain Wizards) and on-line status 

35 screens accessible through the Control Center interface. As 
shown in FIG. 50, to view or open the Control Center, the 
user can right-click the icon in the system task status bar, 
then select the desired view from the list of configurable 
items presented in menu 572, including Devices 574, Sock- 
ets 576 and Applets 578. 

The Devices Mews (FIGS. 51-54) displays the current 
status of all the Devices currently accessible. For instance, 
in window 580 (FIG. 51), this view contains the General tab 

45 582, Link tab 584, Device tab 586 and Diagnostics tab 588. 
As the name implies, the General tab 582 provides general 
information related to the connected device. The name field 
582a holds the user name given to the device during its 
configuration. The Vendor field 582b holds the name of the 

50 device's vendor. The Model field 582c holds the model 
name of the device. The Version field SS2d holds the 
firmware version number taken from the device. Finally, the 
Equipment Identifier field 582e holds the manufacturer's 

55 equipment number taken from the device. 

The Link Tab 584 displays communication port related 
parameters and the content of this tab will be different 
depending on the device type being viewed. As shown in 
FIG. 52, the Port field 584a displays the communications 

60 port with which the device is associated, such as COM1, 
COM2 and so forth. The Baud field S$4b indicates the 
current baud rate at which the wireless control program 
subsystem will communicate with this device. 

6S As shown in FIG. 53, the Device Tab 586 contains the 
device signal strength field 586a, battery life field 5866, and 
network address field 586c. Finally, the Diagnostics tab 588 
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(FIG. 54) displays descriptive messages, such as messages 
contained in field 588a, that relate to the devices' current 
internal and network status. 

As described above, the present invention differs signifi- 
cantly in many ways from traditional methods of program- 
ming for and configuring wireless devices. Just as languages 
like "Visual" type programming languages like Visual Basic 
and Visual C++ made it easier and faster to deploy Windows 
applications, the present invention makes wireless program- 
ming easier and faster and more intuitive than previous 
approaches such as direct device access and middleware. 
Numerous benefits from the present invention are achieved 
such as: support for 32-bit multithreaded operating systems; 
an "industry-standard" interface module; an event-driven 
(non-polled) model; an integrated GUI-based control center; 
and integrated GUI-based configuration "wizards." As to 
32-bit multithreaded support, the present invention supports 
overlapped I/O, UNICODE, and follows a purely asynchro- 
nous event-driven paradigm. 

The industry standard interface module of the present 
invention exposes to the programmer interfaces for which to 
program. This can include, for instance, proprietary ActiveX 
controls such as MobileX™ offered by DMD as well as 
interfaces such as a true Winsock 2 driver or ODBC driver. 

In terms of providing an event-driven paradigm, the 
present invention can deliver an event message to the 
application for virtually any status change within any con- 
nected devices or networks. This approach not only saves 
CPU cycles, but gives an exact representation of the wireless 
happenings, saving battery life on the device and the CPU, 
and allowing applications to be written more intuitively. 

Advantageously, the present invention can run without 
any other applications. Once installed, it already has the 
ability to connect any configured devices in the system and 
register them with the wireless network A "control center" 
view can be provided to such that a user can tell whether the 
wireless device is activated for the particular wireless net- 
work as well as other items such as wireless network 
coverage check, battery level, diagnostics, etc. The control 
center also supports a full range of system diagnostics and 
status, all without requiring the development of a separate 
application. With the present invention, a user can obtain 
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diagnostic and status information about the wireless device 
and the network such as registration status, signal strength, 
and the device's address. As shown in FIG. 53, for example, 
the wireless devices "Lan" and "PocketPlus" are shown to 
be connected and the wireless device "PIA Card" is on-line. 
Diagnostics are shown in Diagnostics window 508a for the 
selected or highlighted device. Configuration "wizards" are 
desirably provided to aid the user in managing wireless 

10 devices, as well as known domain and host configurations. 
The present invention, in addition to providing a pro- 
gramming interface, is an operating system extension that 
exists close to the operating system and allows it to be 

15 configured via the Windows Control Panel and Windows 
shell. Once running, the extension is visible as an icon in the 
Windows Task Tray and can be easily activated for diag- 
nostic reporting and viewing of the running devices and 
connections. The wireless control program subsystem 

20 implementing the present invention reacts appropriately to 
system events such as shutting down Windows and power 
management functions. 

The present invention provides overlapped input/output 

25 by aligning the present invention closely with the operating 
system. For instance, the present invention allows for the 
running of programs simultaneously with the sending and 
receiving of data. This provides optimum use of the avail- 
able wireless devices and wire-line connections. 

Again, the present invention uses system events and can 
respond to such events given out by the system. For 
example, the present invention knows when a device is 
about to go to "sleep" by virtue of receiving a system event 

35 sent to all processes by the Power Management features in 
Windows. Middleware, by contrast, ignores this valuable 
piece of information. The present invention uses this infor- 
mation advantageously to prepare for the shut down and to 
recover gracefully upon a system restart. 

40 

As these and other variations and combinations of the 
features discussed above can be utilized without departing 
from the present invention as defined by the claims, the 
foregoing description of the preferred embodiments should 
45 be taken by way of illustration rather than by way of 
limitation of the present invention. 
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APPENDIX A: 

Header files MAddress.h, MEvent-h, MName.h, MProviderEvent.h, MSocket.h, 
MSocketCodes.h, MSocketErrors.h. 



54 
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! MAddress.h ^~^"^~™~^ Pa 9 e 1 



// Copyright© 1997 Dynamic Mobile Data, Inc. All rights reserved. 
//M Address, h 

// 

// Mobile Address specification 

// 

#if Sdefmed ( _MAddress_ ) 
#define MAddress 

#if !defmed( MSOCKENTRY ) 

#if defined ( MSocketDLL ) 

#defme MSOCKENTRY _declspec(d II export) 

#elif defined ( AirdromeEXE ) 

#defme MSOCKENTRY 

#elif defined { UNDER_CE ) 

#defme MSOCKENTRY 

#else 

#defme MSOCKENTRY _declspec(dtlimport) 
//#else 

//#error EXPORT/IMPORT not specified 

#endrf 

#endif 

#include "MName.h" 

// 

// Address family extension with Mobile Socket address family 

// 

// at the moment 04.16.97 AF_MAX is equal 22 (in Winsock.h) 
#define AF_MOBILE 22 

// NULL address for CDPD and RAM and ??? - should it be defined somewhat differently 
#define MADDR_NULL 0 

// 

// IP port specification. 

// Only NULL value - all values really used by Mobile software 

// has to be specified dynamically at configuration time. 

// If there is no any value specified at configuration time 

// airdrome going to update configuration with DefeultConfigurationValue 

// which is hardcoded below: 

// 

ftdefine MPORT NULL 0 

#define MPORT MOBILE SHIFT OxOOaa f* shift value to be added to minimum allowed user port V 
#define MPORTJ3EFAULT_MSOCKSERVICE ( IPPORT_RESERVED + MPORT_MOBILE_SHIFT ) 
// IPPORT RESERVED defined in Winsockii 



m 



ff 

li Domain specification 
// 

#define MDOMAIIM NULL 0x0000 /*not specified*/ 

#define MDOMAIN~DEFAULT 0x0001 /"default domain value should be used*/ 
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#define MDOMAIN_ANY 0x0002 Tany domain could satisfy*/ 

// 0x0003 - 0x0100 reserved for future Mobile internal use 

#deftne MDOMAIN_CDPD 0x0101 /'native CDPD*/ 

tfdefme MDOMAIN_RAM 0x01 02 Tnative RAM"/ 

#define MDOMAIn[aRDIS 0x01 03 T native ARDIS"/ 

// 0x0104 - 0x1000 reserved for future native networks providers 

// any domain id from the interval 0x1 001 - 0x7fff could be used as customer domain id 

// 0x8000 - Oxffff just reserved 

#define MDOMAIN_CUSTOMSTART0x1001 

#define WDOMAlN_CUSTOMEND 0x7fff 

// Below are some definitions as a substitution (or introducing) 

// for the name space portion of the implementation. 

#define MAX_A1R_NAME 15 

#define MAX SERVICE.NAME MAX.AIR.NAME 

#define MAX_HOST NAME MAX_AIR_NAME 

#define MAX_DOMaTn_NAME MAX_AIR_NAME 

// maximum sizes of the exproted address 

#define MAX_BINARY_PART (sizeof{unsigned $hort)+sizeof(unsigned char )+sizeof (unsigned 
shor1)+sizeof(unsigned long)+sizeof(unsigned short)) 
#define MAX_EXPORT.SI2E 

(MAX_BINARY_PART+MAX_SERVICE_NAME+MAX.HOST_NAME+MAX_DOMAIN_NAME+3) 

// address format specification bit definition 
#defme MAddrPort 0x01 
#define MAddrService 0x02 
#define MAddrDomainld 0x04 
#defme MAddrDomainName 0x08 
#define MAddrAddress 0x10 
#define MAddrHost 0x20 



□ 



H 1 typedef enum _ExportRules { 

^ ExRule.AII = 1 , // exports all binary fields and all valid names: 
£= ~ // address, domain Id, port, 

m //host (if valid), 

// domainName (if valid), 
// service (If valid) 
ExRule_Binary, // exports all binary and no any names 

// address, domainld, port 
ExRule ValidBinary, // exports only valid binary and no any names 
// address (if valid), domainld (if valid), 
//port (If valid) 

ExRule_ClientConnect, // typical client connection request (if any 
// of the required values are not available 
// Export function wDI return false): 
// address or host (If address not valid). 
// (if none of them return false) 

// domainld or domainName (if Id not valid) 
// or none of them (if both not valid), 
// service or port (if service is not specified 
// but port is) 



56 



11/06/2003, EAST Version: 1.4.1 



41 



US 6,628,965 Bl 



42 



| MAddre 



// (if none of them return false) 

ExRule_ClientSelf, // client self address in connection request: 
// address. 
// port, 

//domain Id (if valid), 
//host (if valid}, 
// service (if valid) 
// domainName (if valid), 
ExRule_ServerAccept, // server self address in connection reply: 
// address, 
// port. 

//domain Id (if valid), 
//host (if valid), 
// service (if valid) 
// domainName (if valid), 
// and so on TBD ?????????????? 
} ExportRules; 

typed ef enum _AddressFormats { 
AddrFormat_Auto = 1, // Mobil itylayer will attempt to determine the address format. 

Q AddrFormatJP, // Network address range validations test will be performed 
y~ // based on IP address range rules. 

u AddrFormatjMobitex // Network address range validations test will be performed 
sj // based on Mobitex address range rules. 

} AddressFcrmats; 

S class MAddress { // WinSock uses address definition as in sockaddr 
7* public: 

L, MSOCKENTRY MAddress( void ); 
U MSOCKENTRY MAddress( unsigned short port ); 
" MSOCKENTRY MAddress( unsigned long address ); 

MSOCKENTRY MAddressj unsigned short port, unsigned long address ); 
MSOCKENTRY MAddress( LPTSTR service. // up to MAX_SERVICE_NAME,if longer - truncated 
unsigned long address // as binary number 

MSOCKENTRY MAddress( LPTSTR service, // up to MAX_SERVICE_NAME,if longer - truncated 
LPTSTR address // in dotted notation 

): 

MSOCKENTRY MAddress( LPTSTR address ); Tin dotted notation*/ 
MSOCKENTRY MAddress( unsigned short port, LPTSTR address ); 
MSOCKENTRY MAddress( MAddress* maddrSrc ); 

MSOCKENTRY virtual -MAddress( void ); 

MAddress& operator=(MAddress& maddrSrc); 

MSOCKENTRY void Erase( void ); 

MSOCKENTRY void Domainld( unsigned short id ) { ..domain = id; } 
MSOCKENTRY unsigned short Domainld( void ) { return _domain; } 
MSOCKENTRY void DomainName{ LPTSTR name ); 
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MSOCKENTRY LPTSTR DomainName( void ); 
MSOCKENTRY void Port* unsigned short port ) { _port = port; } 
MSOCKENTRY unsigned short Port( void ) { return _port; } 
MSOCKENTRY void Service* LPTSTR name ); 
MSOCKENTRY LPTSTR Service* void ); 

MSOCKENTRY void Address Format* Address Formats format ) Ijaddr Format = format;} 

MSOCKENTRY bool Address* unsigned long address ); 

MSOCKENTRY unsigned long Address* void ) { return _addr; } 

MSOCKENTRY bool Address* LPTSTR address ); 

MSOCKENTRY bool AddresslnDots* LPTSTR to , unsigned short tolen ); 

MSOCKENTRY void Host* LPTSTR name ); 

MSOCKENTRY LPTSTR Host* void ); 

// following methods responcible for MAddress translation from/to 
// in-air format to/from MAddress object. In-air address presentation 
// described below: 

II unsigned short family; // Should be AF_MOBILE for Mobile Socket address family (see above) 
// required by WinSock2 here and should be two bytes length 
// Should be in host byte order (not network byte order). 
// AF JNET value used by TCP/IP 
// unsigned char flags; // address format specification: 

p // P - binary port value present (MAddrPort) 

// S. - service name present (MAddrService) 

; Ui ' // I.. -domain id present (MAddrOomain Id) 

V) //.,.. D... - domain name present (MAddrOomainName) 

is'i // ...A .... - binary address value present (MAddrAddress) 

jg // ..H - host name present (MAddrHost) 

^ // RR - reserved 

f: // the rest of the fields has to be in network byte order 

f // unsigned short port - present only if MAddrPort is up 
L If unsigned long addr - present only if MAddrAddress is up 
^ // unsigned short domain - present only if MAddrOomainld is up 

// NameSpec service - present only if MAddrService is up 
^ // NameSpec host - present only if MAddrHost Is up 
if // NameSpec domainName - present only if MAddrOomainName is up 
^ // where NameSpec defined as following: 

^ // unsigned char length - length of the name not including this byte itself 
// char nameflength] - array of length bytes with the name in It 

// converts this object to in-air format. 

// Exporting fields set determined by rules. 

// Returns number of bytes in exported format or zero 

MSOCKENTRY unsigned short Export(void* to, unsigned short toMax, ExportRules rules); 
// converts from in-air address to this object. Returns 0 if UNSUCCESSFUL, 
// otherwise number of bytes used in from 

MSOCKENTRY unsigned short tmport(void* from, unsigned short fromLimlt); 

static unsigned long RetrieveAddressfvoid * row, unsigned short limit); 
static unsigned short RetrievePort (void * row .unsigned short limit); 
// print out row address in text format 

static bool Printout* void * row.unsigned short limit, LPTSTR bet, unsigned short size); 

bool Printout* LPTSTR bet, unsigned short size); 
// by given memory where address is written 
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// returns length of this memory 

static unsigned short RowLength(void* row, unsigned short limit); 
// static unsigned long ConvertLongOrder( unsigned long value); 
// static unsigned short ConvertShortOrder( unsigned short value); 
private: 

// unsigned short NetOrderPort( void ); 

// void PortFromNetOrder( unsigned short port); 

// unsigned long NetOrderAddr( void ); 

// void AddrFromNetOrder( unsigned long address); 

// unsigned short NetOrderDomain( void ); 

// void DomainFromNetOrder< unsigned short domain); 

// following fields in this object are in host byte order, but 

// in in-air fromat they have to be in network byte order 

unsigned short _port; 

unsigned long _addr; 

unsigned short _domain; 

MName * _service; 

MName' _host; 

MName * _domainName; 

Address Formats ^addrFormat; 

^ I; 
U #endif 



P 
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// Copyright © 1997 Dynamic Mobile Data, Inc. Ail rights reserved. 
// MEvent.h 

// 

// Mobile Event specification 

// 

mf (defined { _MEvent_ ) 
#define MEvent 

// Socket events 

// Standard events FD_READ, FD_WRITE, FD OOB, FD.ACCEPT, 
// FD.CONNECT. FD.CLOSE. FD.QOS, FDJ3ROUP_QOS. 



//Additional events.. 



#if defined ( UNDER_CE ) 
// Winsock 1 .0 does not have it 
^define FD_MAX_EVENTS 8 
#endif 

^ // new confirmation information arrived 
t #define MFD_DELIVER_BIT FD_MAX_EVENTS /*8V 
*f #define MFDJDELIVER (1 « MFD_DELIVER_BIT) 
^; // property changed 

#define MFD.PROPERTY BIT (FD MAX_EVENTS + 1) 
W #define MFO_PROPERTY (1 « MFO_PROPERTY_BIT) 
^ // error condition for a socket 

C #define MFD_ERROR_BIT (FD_MAX_E VENTS + 2) 
#define MFD_ERROR (1 « MFD_ERROR_BIT) 



□ class MEvent { 
M protected: 

MEvent( void ); 

public: 

(g virtual -MEvent( void ); 
public: 

virtual unsigned short Type< void ) = 0; 
virtual LPCTSTR TypeName( void ) = 0; 
virtual unsigned long Code{ void) { return 0; }; 
virtual LPCTSTR Description( void ); 

}; 

class MEventError: public MEvent { 
public: 

MEventError( unsigned long code ); 
virtual -MEventError< void ); 

virtual unsigned short Type{ void ) { return MFD_ERROR; } 
virtual LPCTSTR TypeName( void ); 
virtual unsigned long Code( void) { return _code; ) 
virtual LPCTSTR Description void ): 
private: 
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unsigned long _code; 

class MEventAccept: public MEvent { 
public: 

MEventAccept(void); 
virtual -MEventAccept(void); 

virtual unsigned short Type( void ) { return FD_ACCEPT; } 
virtual LPCTSTR TypeName( void ); 
virtual LPCTSTR Description void ); 

}; 

class MEventClose: public MEvent { 
public: 

MEventClose{unsigned long code); 
virtual ~MEventClose(void); 

virtual unsigned short Type{ void ) { return FD_CLOSE; ) 
virtual LPCTSTR TypeName( void ); 
virtual unsigned long Code< void) { return _code; ) 
virtual LPCTSTR Description void ); 
private: 
unsigned long _code; 

); 

class MEventRead: public MEvent { 
public: 

MEventRead(unsigned long number.unsigned long length.unsigned long count); 
virtual -MEventRead{void); 

virtual unsigned short Type( void ) { return FD_READ; ) 
virtual LPCTSTR TypeName( void ); 
virtual LPCTSTR Description( void ); 
unsigned long Sequence( void ) { return _number; } 
unsigned long Lengm( void ) { return Jength; } 
unsigned long Count( void ) { return _count; } 
private: 

unsigned long ^number, 
unsigned long Jength; 
unsigned long _count; 

); 

class MEventWrite: public MEvent { 
public: 

MEventWritetunsigned long number.unsigned tong length.unsigned long total); 
virtual -MEventWrite(void); 

virtual unsigned short Type( void ) { return FD_WRITE; ) 
virtual LPCTSTR TypeName( void ); 
virtual LPCTSTR Description ( void ); 
unsigned long Sequence( void ) { return _number; ) 
unsigned long Length{ void ) { return Jength; ) 
unsigned long Total( void ) { return Jotal; } 
private: 
unsigned long _number, 
unsigned long Jength; 

unsigned long Jotal; // total number of bytes for all of the messages 

class MEventDeliver: public MEvent { 
public: 



61 



11/06/2003, EAST Version: 1.4.1 



US 6,628,965 Bl 



51 



52 



I MEvenflT 



Page 3 



MEventDeliver{unsigned long number.unsigned long bytes); 
virtual -MEventDelrver(vold); 

virtual unsigned short Type< void ) { return MFD_DELIVER; } 
virtual LPCTSTR TypeName( void ); 
virtual LPCTSTR Description! void ); 
unsigned long Sequence( void ) { return _number; } 
unsigned long Bytes( void ) { return _bytes; ) 
private: 

unsigned long _number; 
unsigned long bytes; 

}; 

class MEventProperty: public M Event { 
public: 

MEventProperty(unsigned long property.unsigned long value); 
virtual -MEventProperty(void); 

virtual unsigned short Type( void ) { return MFD.PROPERTY; } 
virtual LPCTSTR TypeName{ void ); 
virtual LPCTSTR Description! void ); 
unsigned long Property^ void ) { return _property; ) 
unsigned long Value( void ) { return _value; } 
private: 

unsigned long ^property; 
unsigned long value; 

}; 

class MEventOOB: public M Event { 
public: 

MEventOOB(unslgned long number.unsigned long length.unsigned long count); 
virtual -MEventOOB(void); 
Hf virtual unsigned short Type( void ) { return FD_OOB; } 
^ virtual LPCTSTR TypeName( void ); 

virtual LPCTSTR Description! void ); 
*"* unsigned long Sequence! void ) ( return _number; } 
p unsigned long Length ( void ) { return Jength; } 
H unsigned long Count ( void ) { return _count; } 
private: 

unsigned long _number; 
unsigned long Jength; 
unsigned long _count; 

}; 

class MEventConnect: public M Event { 

public: 

MEventConnect(void); 
virtual -MEventConnect(void); 

virtual unsigned short Type( void ) { return FD_CONNECT; } 
virtual LPCTSTR TypeName! void ); 
virtual LPCTSTR Description void ); 

); 

#endif 
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// Copyright © 1997 Dynamic Mobile Data, Inc. All rights reserved. 
// MNams.h 

// 

// Mobile Name specification 

// 

#if [defined ( _MName_ ) 
^define __MName_ 

class MName { 
public: 

MName( void ); 

MName( LPTSTR name ); 

-MName( void ); 

LPTSTR Name( void ); 
bool Valid( void ); 

// space requirement for Export. Since it always exported as ASCII 

// it returns size for the ASCII presentation of the name 

unsigned short Space(void); 

bool Export( void * to, unsigned short toLen); 

bool lmport( void * from, unsigned short fromLirnit); 

// return length of the name itself without leading ten char 
static unsigned short RowLength(void* row); 
static bool PrintOut( void* row, LPTSTR txt, unsigned short size); 

bool PrintOut( LPTSTR txt. unsigned short size); 
private: 

LPTSTR _name; 

}; 



#endif 
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// Copyright © 1997 Dynamic Mobile Data, Inc. All rights reserved. 
// MProviderEvent. h 

// 

// Mobile Provider Event specification 

// 

#if Idefined { _MProvlderEvent_ ) 
#define MProviderEvent 

// Provider status change 

#defineMPE STATUS_BIT 0 

#define MPE.STATUS (1 « MPE_STATUS_BiT) 

// On property change 

#defineMPE PROPERTY BfT 1 

#deftne MPE_PROPERTY (1 « MPE_PROPERTY_BIT) 
// Provider network event 
#defineMPE NE7WORK_BIT 2 

#define MPE.NETWORK (1 « MPE_NETWORK_BfT) 
// Status codes: 

#define MPE_STATUS_CLOSEO 1 
n #define MPE_STATUS.NO ACCESS 2 
f, #define MPE STATUS ABSENT 3 
£ #define MPE STATUS OFF 4 

#define MPE_STATUS_ON 5 
Q #defineMPE_STATUS_ONLINE 6 
^ Hfdeflne MPE_STATUS_CONNECTED 7 

*~ // Property codes: 

,b * #define MPE_PROPERTY_ID 1 riocal id of the radio unit*/ 

? . #define M P E_P ROPE RTY_N AM E 2 /'local name of the radio unit*/ 

C #define MPE_PR0PERTY_VEND0R 3 Tdevice manufacturer*/ 

s #define MPE_PROPERTY_MODEL 4 Tdevice model*/ 

'** #deflneMPE PR0PERTY_VERSION 5 /"device firmware/hardware version*/ 

& #define MPE~PROPERTY_EOUIPMENT 6 /'device unique Id*/ 

#define MPE_PROPERTY_ADDRESS 7 /'device address in the network*/ 
£w #define MPE_PROPERTY_BATTERY 8 /'remaining battery life in %*/ 
#define MPE PROPERTY_CHANNEL 9 rradio channel in use*/ 
#define MPE.PROPERTY SERVICEID 10 /*radio service provider id*/ 
#define M P E_P ROPERTY_TOWER 1 1 /Vadio cell/tower id*/ 
#define MPE_PROPERTY_SIGNAL 12 Tcurrent signal strength*/ 
#define MPE_PROPERTY_SOCKETS 1 3 /"number of served sockets*/ 

// Network codes: 

class MProviderEvent { // abstract base class for all the events 
public: 

MProviderEvent(void); 

-MProviderEvent(void); 

virtual unsigned short Type( void ) = 0; 
virtual LPCTSTR TypeName{ void ) = 0; 
virtual unsigned long Code( void ) = 0; 
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virtual LPCTSTR Description! void ); 
virtual unsigned long Number! void ) { return 0; ) 
virtual LPCTSTR Slring( void ) { return NULL; } 

); 

class MProviderStatus: public MProvlderEvsnt { 
public: 

MProviderStBtus(unsigned long code); 
*MProviderStatus(void); 

virtual unsigned short Type( void ) { return MPE_STATUS; } 
virtual LPCTSTR TypeName( void ); 
virtual unsigned long Code( void ) { return _code; } 
virtual LPCTSTR Description! void ); 
private: 

unsigned long _code; 

): 

class MProviderProperty: public MProviderEvent { 
public: 

MProviderProperty(unsigned long code.unsigned long value); 
-MProvlderProperty(void); 

virtual unsigned short Type( void ) { return MPE_PROPERTY; ) 
virtual LPCTSTR TypeName( void ); 
virtual unsigned long Code{ void ) { return _code; } 
fig virtual LPCTSTR Description( void ); 
virtual unsigned long Number( void ); 
virtual LPCTSTR String( void ); 
private: 
unsigned long _code; 
unsigned long _value; 
TCHAR * _str; 

>; 

class MProviderNetwork: public MProviderEvent { 
public: 

MProviderNetwork(unsigned long code t unsigned long value); 
*MProvWerNetwork(void); 

virtual unsigned short Typef void ) { return MPE_NETWORK; ) 
virtual LPCTSTR TypeName{ void ); 
virtual unsigned long Code( void ) { return _code; } 
virtual LPCTSTR Description! void ); 
virtual unsigned long Number( void ); 
virtual LPCTSTR String! void ); 
private: 
unsigned long_code; 
unsigned long _value; 

}; 

#endif 
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// Copyright © 1997 Dynamic Mobile Data, Inc. All rights reserved. 
// MSocket.n 

// 

// Mobile Socket specification 

// 

// Class MSocket intended to provide "Winsock like" features to its user, 

// All possible effort was made to make Mobile interface 

// as simple as possible. At the same time all basic Winsock 

// functionality preserved with the exeption of name 

// resolution service. Currently it is nit implemented at all. 

// As a base for future standard Winsock2 SPI interface 

// implementation MSocket introduces a new address family. 

// For detail description of this family see MAddress.h file 

// and airdrome description. 

// How to use this class 

// - the best way to use this class is to derive yout own class from it 
// and overwrite virtuals which will make possible for you to get event 
// notifications; 

If - another way of this class usage is just instanciate an object (or more) 
// of this class, 

□ 

P #rf [defined ( _MSocket_ ) 
^ #define _MSockeL_ 

y include "MSocketErrors.h" 
53 #include "MAddress.rT 
p include "MEventh" 

#include "MProviderEvent.rT 

£ 

m ldefined( M SOCK ENTRY ) 
p #if defined ( MSocketDLL ) 

#define MSOCKENTRY _declspec{dllexport) 
STa #€lse 

yj #define MSOCKENTRY __dedspec(dllimport) 

/terror EXPORT/IMPORT not specified 

#endif 

#endif 



#define MRETCODE unsigned long 
#define M_UndefmedValue OxfffffTff 

// redefinitions of the standard Winsock2 error codes 

#define MRC_VERSION_NOT_SUPPORTED WSAVERNOTSUPPORTED 

#defineMSG READ 0x0000 
#define MSG SKIP 0x0008 

#define MSG_REMOVE ( MS G_PARTI AL | MSG.SKIP) 
// Socket options as defined in Winsock2 specification 
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// 

// SO ACCEPTCONN BOOL is Listen()ing 

// SoIbROADCAST BOOL is configured for the transmission of 

// broadcast messages 

// 

// SO_OOBINLINE BOOL OOB data is being received as pert 
// of normal data stream 
// and so on 

// 

// Socket options specific to MSocket specification presented 
// in the following table: 

// NAME NAMECODE TYPE DEFAULT 

// open real radio connection immediately versus awaiting 
// for outbound data 

// OR reply to Incoming connection Immediately on Acceptance 
// versus awaiting for backward data flow 
#define MSO_ForcedConnection 0x0001 0000 r bool false 7 

// transmit data without awaiting for successfull handshaking 
^define MSO_ForcedData 0x00020000 /* bool false 7 

// data compressed on a per message basic 
fldefine MSO_Compression 0x00040000 f bool false 7 

// data encrypted on a per message basic 
tfdefine M SO Jvlessage Encryption 0x00080000 T bool false 7 
U // data encrypted for the whole connection 

SI #defme MSO_ConnectionEncryption 0x001 00000 /• bool false 7 
UJ // C2 security level for connection establishing 

$i #detlne MSO_C2Securlty 0x00200000 r bool false 7 

U U OOB data is being recieved as data stream 

#define MSO.OOBDataBytes 0x00400000 r bool false 7 
u // OOB data Is being recieved as message stream 

~i #define MSO_OOBDataMessages 0x00800000 r bool true 7 



// socket priority as number in interval 0-0xffff. 

// were 0 is the higest and OxfffT "no priority specified" 
#defrne MSO_Priority 0x0a0O8 r long 0 7 

// socket allowed out of coverage time is a time interval 

// within the range 0-Oxfffff seconds. If it is bigger then Oxfffff 

//it is treated as INFINITY 
#defme MSO.OutOf Coverage 0x0a010 r long 3600 - 1 hour 7 

// all kind of different DMD socket implementation specific 

// options could be brought on this level. 

// The question is weather we want it to be exposed to user 

// or not. Parameters like following: 

// different kinds and levels of data confirmation mechanizms, 

// SNMP enabling/disabling and specification, 

// routing support, 

// domain support, 

// all kind of name resolution support {applicattons.hosts, 
// users.servlces, domains, wires, and cables) 

// data confirmation based on time is ON 
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#deftne MSO_ConfByTimeou1 0x01 000000 /* bool true 7 
// data confirmation with every packet is ON 

#define MSO_ConfPiggyback 0x02000000 /* bool true '/ 
// data confirmation for data retrieval by user 

#defme MSO_ConfUser 0x04000000 r boot true 7 
II data confirmation on Airdrome level 

#define MSO_ConfAtrdrome 0x08000000 /* bool true 7 



//Socket properties 

// 

// (Don't forget that following info is provided for each socket. 
// Same info for the radio link (modem or direct connection) 
// is available on a system level by means of Airdrome,) 

// 

// socket state could have one of the following values 
#define MSP.StateCreated 0 
#define MSP_StateClosed 1 
#define MSP.StateConnected 2 
#define MS P~State Disconnected 3 
#define MSP_StateConnecting 4 
#define MSP_$tateDisconnecting 5 
#define MSPlstateUstenlng 6 
#define MSP_StateError 7 



K // number of messages pending in incoming queue (unread by user) 
% #define MSP_MessagesPending 0xb402 Hong*/ 
^ // number of bytes pending in incoming queue 
■ #define MSP_BytesPending 0xb403 Dong*/ 

;' // number of bytes pending in the first message in incoming queue 
Z #define MSP^ByteslnMessagePending Oxb404 Hong*/ 
H // number~of messages pending in incoming OOB queue (unread by user) 

#define MSP_OOBMessagesPending 0xb405 Hong7 
& II number of bytes pending in incoming OOB queue 
£ #define MSP_OOBBytes Pen ding 0xb406 Hong*/ 

// number"of bytes pending in the first message in Incoming OOB queue 
#define MSP_OOBByteslnMessegePending 0xb407 Hong*/ 



// number of data bytes given by user to send out 

#define MSP.BytesSent 0xb001 /* long 7 

// number of data bytes actually sent out (without retransmissions) 

#define MSP_BytesSentActual 0xb002 /* long 7 

// number of data bytes retransmitted (sent more then once) 

#defme MSP_BytesRetransmitted 0xb003 r long 7 

// number of data bytes confirmed by other side of the socket 

#deftne MSP_BytesConflrmed 0xb004 r long 7 

// number~of data bytes received (not nesseccarily retrieved by app) 

#define MSP.BytesReceived 0xb005 /* long 7 

// number of data bytes received more then once 

#define MSP_BytesDupIicated Oxb006 r long 7 

// number of messages given by user to send out 



#define MSP_SocketState 



0xb401 Hong7 
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tfdefrne MSP_MessagesSent Oxb007 r long V 

// number of message? actually sent out 

#define MSP_MessagesSentActual 0xb008 /* long V 

// number of messages confirmed by other side of the socket 

// (WE HAVE DELIVERY NOTIFICATION, WHICH IS NOT THE SAME AS LOW LEVEL 

CONFIRMATION 

It AND I NOT SURE THAT THIS THING HAS TO BE ACCESSIBLE BY USER ????????? ) 

//#define MS P_Mes sages Confirmed Ox r long •/ 

// number of messages received (not nesseccarily retrieved by app) 

^define MSP_Messages Received OxbO09 1* long •/ 

if bytes received over the air (including all possible headers and data) 

#define MSP_AirlnTraffic OxbOOa f* long 7 

// bytes sent over the air (including all possible headers and data) 

#deflne MSP_AirOutTraffic OxbOOb r long 7 

// packets sent 

#define MSP_PacketsSent OxbOOc r long 7 
// packets received 

tfdefme MSP_Packets Received OxbOOd t* long 7 

// For all time related properties value M JJndefinedValue 

II means that the event under question never happened 

// time of the MSocket creation as a number of seconds 
H II elapsed since midnight (00:00:00), January 1, 1970, 
^ // coordinated universal time (see time() function description) 
CI tfdefme MSP_TimeStarted 0xb101 /*long7 

II time of the ConnectQ or Listen () call. 
*S // Presented as a number of seconds since Started. 
S fcjefme MSPJImeConnected 0xb102 /*long7 
j*f // time of the first real wireless packet was sent out. 

// Presented as a number of seconds since Started. 
5 tfdefine MSPJTimeFirstOut 0xb103 /'long*/ 
^ // time of the first real wireless packet arrival 
p // from the other side of the socket. Presented as a number 
H // of seconds since Started. 
^ #define MSP_TimeFiretln 0xb104 HongV 
C? // time of the air connection usage as a number of 
OS // seconds since Firstln or FirstOut (whoever is earlier) 

#define MSP_TimeUplnA!r 0xb105 /long*/ 

// time of the last real wireless packet was sent out. 

// Presented as a number of seconds since Started. 

#defme MSP_TimeLastOut Oxb 1 06 /*long7 

// time of the last real wireless packet arrival 

// from the other side of the socket. Presented as a number 

// of seconds since Started. 

#defme MSP JTimeLastln Oxb 1 07 Hong*/ 

// speed ofthe actual outbound data transmission In baud 

#define MSP_BaudOutActua! 0xb201 HongV 

// speed oTthe actual inbound data flow in baud 

#defme MSP_BaudlnActual 0xb202 Hong'/ 

// speed of the maximum possible outbound data 

// transmission In baud (for given equipment on 

// the both sides of the socket, without any concurrent 

// live transmissions and under good coverage conditions 
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II based on real live data) 

#define MSP_BaudOutMax 0xb203 /'long*/ 

// speed of the maximum inbound data flow in baud 

// See comment above. The value could be different due 

// to the different data flow direction. 

#define MSP_BaudlnMax 0xb204 Hong*/ 

// 

// other properties could be appended to this enumeration 



// Here we have radio provider section 

// 

// It looks like the only thing what MSocket user may 

// have to be aware is RadioProvider Events. 

// Such things as properties (something to know about 

// radio provider which is not dynamic, but static) 

// and options (some parameters which could be changed 

// by user) should be outside of the MSocket scope. 

// They definetely going to be available via Airdrome GUI 

// and via Mobile software integrated into operating system 
□ // like Control Panel extension and Property Pages Shell 
,n II extension. 

u // They also zouM De available to the user by means of some 
i i II other object and/or API, and/or interface to COM object??? 

i?! // 
£ // 

» // All radio provider specific parameters including Options, 

^ // Properties, and Events are very much dependent upon particular 

// radio provider. I think at this stage of the product development 
* // it is reasonable not to define all possible parameters, but rather 
,f *t II make all possible efforts to implement all of them. After 
^ // implementation completion we will have to decide which parameters 
H // we are going to expose for end user, which parameters we are 
?D // going to make available at the configuration time (some of them 
*3 // could be available for user and some of them not), and when parameters 
G@ // are going to be hardcoded in our implementation and not available for 

// any alterations/adjustments (like number of retries and modem 

// error recovery actions). 

II Radio provider option 

// for Sierra Wireless could be any number from 0 to 8 
//#define M RPO_BAU DRATE 0xd001 Hong*/ 

// and so on 

// Radio provider property 

/^define MRPP_COMPORT 0xd101 /long*/ Tmodem only*/ 

/flWeflne MRPPJPPORT 0xd102 Hong*/ TCDPD internet connection only*/ 

//#define MRPPJP ADDRESS 0xd103 Hong*/ TCDPD only*/ 

// and so on 

#if defined ( UNOER_CE ) 



70 



11/06/2003, EAST Version: 1.4.1 



69 



US 6,628,965 Bl 



70 



/• WinSock 2 extension - WSABUF struct 7 
typedef struct _WSABUF { 

ujong ten; f the length of the buffer V 

char FAR * buf; /* the pointer to the buffer */ 
} WSABUF, FAR * LPWSABUF; 

/• WinSock 2 extension - manifest constants for shutdown() 7 

#define SD_RECEIVE OxOO 

#deftne SD_SEND 0x01 

#define SD_BOTH 0x02 

#endif 

class ApplicationSidelmp; 
class MSocket { 
public: 

MSOCKENTRY MSocket(void); 

MSOCKENTRY MSocket(int type); // type could be SOCK_STREAM or SOCK_DGRAM 
(I closes actual connection (options lor the connection 
II closing process specified by socket options) if it was not 
II closed by Shutdownf). 

// Releases all the resources allocated for the socket. 
MSOCKENTRY virtual -MSocket(void); 

f% 

5 // type could be SOCK_STREAM or SOCK_DG RAM 
U MSOCKENTRY MRETCODE Type(int type); 

= - : // see list of possible and supported options above 

% MSOCKENTRY MRETCODE SetOption{int option, void * value, int length); 

'q MSOCKENTRY MRETCODE GetOption(lnt option, void * value, int length); 

^ // retrieves state property value (see list of properties above) 
, £ . // (This function is analogous to the select() function in BSO) 
^ MSOCKENTRY MRETCODE State(int property, void * value. Int length); 

K II assosiates a socket with local address 

5 MSOCKENTRY MRETCODE Bind( MAddress & local ); 

^ // connect to other side of the socket 

^ MSOCKENTRY MRETCODE Connect( MAddress & to, 

WSABUF * caller » NULL, 

WSABUF # cailee = NULL 

// QOS is not supported by now. 

// Due to intention not to overcomplicate 

// implementation and QOS could be easily 

// supported later (does not require any 

// additional data to be transferred 

// over the air) 

); 

// makes socket listening for incoming connections for 

// specified local address (as was prodided by blnd()) 

MSOCKENTRY MRETCODE Listen(void); 

// user of this class has to provide a new object of 

// the users dass derived from MSocket. 

// This object will be used by this method to assign first 

// connection from an incoming connections queue 



71 



11/06/2003, EAST Version: 1.4.1 



71 



US 6,628,965 Bl 



72 



JMSocketh . ■ - Page" 1 



MSOCKENTRY MRETCODE Accept{ MSocket & connection /*inout7); 

// terminates actual in and/or. out connection {options for 
// the connection dosing process specified by socket options). 
// how could have SD_RECEIVE. SD.SEND. SD.BOTH 
MSOCKENTRY MRETCODE ShutdOwn( int how ); 

// retrieves an address of a connected peer (if any) 
MSOCKENTRY MRETCODE Peer( MAddress* & remote ): 
// provides it's own local address 
MSOCKENTRY MRETCODE Self( MAddress* & local ); 

// retrieve data from inbound queue. 

// length is IN-OUT parameter and has a buffer size on a way IN 

// and message size on a way OUT 

// actual returns number of bytes retrieved 

// flags id IN-OUT parameter and could have ORed MSG.PEEK, 

// MSG_OOB, and MSG_PARTIAL 

// And DMD addition - MSG_REMOVE (meaning to remove a message 

// from the queue without any regard to the buffer size or presence) 

// MSG_READ Is a definition which is zero. Could be used to specify normal reading. 

MSOCKENTRY MRETCODE Receive( void * buffer, 

int & length, 

int & actual, 

int & flags 

); 

// retrieve data and Sender MAddress from inbound queue. 

// It is strongly recommended to use this function only for 

// datagramm sockets. (Which in reality means that we may don't 

// implement it in the first cut at all.) 

// actual returns number of bytes retrieved; 

MSOCKENTRY MRETCODE Receivef MAddress*& from, 

void * buffer, 

int & length, 

int & actual, 

int & flags 

); 

// disconnect other side of the socket and return disconenction 

// data. Since MSocket supports asyncronous 10 disconnection data 

// available only on receiving FD_CLOSE event 

MSOCKENTRY MRETCODE Receive Disconnect* WSABUF & disdata ); 

//flags could hove ORed MSGJDONTROUTE, MSG_OOB, and MSG_PARTIAL 
MSOCKENTRY MRETCODE Send(void* buffer, int length, int & actual, int flags = 0); 
MSOCKENTRY MRETCODE Send(MAddress& to.void' buffer, int length, int & actual, Int flags); 
MSOCKENTRY MRETCODE Send Disconnect WSABUF & disdata ); 



II Event() function is a replacement for select(). 

// WSAAsyncSelect(), and WSAEventSeiect() functions 

// in Winsock specification. 

// mask could have any combination of the standard events. 
// Additional events introduced by means 
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II of MFD_MSOCKET_EVENT. (See ■MEvent.h") 

MSOCKENTRY MRETCODE Event( long mask ); 

// if user wants to receive events notifications 

// function should be overitten In derived class 

MSOCKENTRY virtual MRETCODE OnEvent( MEvent & event ); 



II Underlying phisical connection provider section 

II 

// see list of possible and supported provider options above 
// MSOCKENTRY MRETCODE ProviderSetOption(int option, void * value, int length); 
// MSOCKENTRY MRETCODE ProviderGetOpUon(int option, void * value, int length); 

// retrieves provider state property value (see list of provider properties above) 

MSOCKENTRY MRETCODE ProvlderState(int property, void * value, int length); 

// see MProviderEvent.h 

MSOCKENTRY MRETCODE ProviderEvent(long mask); 

MSOCKENTRY virtual MRETCODE OnProviderEvent( MProviderEvent & event ); 

MSOCKENTRY static MRETCODE Startup (unsigned short version, WSAData & description); 
MSOCKENTRY static MRETCODE Cleanup(void); 
// returns string to be used as Mobile return code description 
MSOCKENTRY static LPCTSTR Text From Code{ MRETCODE code); 
private: 

static void * _a; 

friend ApplicationSidetmp; 

); 

#endif 
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// Copyright © 1997 Dynamic Mobile Data, Inc. All rights reserved. 
// MSocketCodes.h 

// 

// Mobile Socket Codes specification 

// 

#if Idefmed ( _MSocketCodes_ ) 
#define MSocketCodes 



JWefineMRC BASEERR 0x00020000 



#defineMRC SUCCESS 0x00000000 
#define MRC~NULL Oxffffffff 
#define MRC_DO_FENI 0x00000001 
#define MRC PROCESSED 0x00000002 
#defmeMRC IN PROGRESS 0x00000003 
#define MRC_DEVICE_NOTCONNECTED 0x00000004 
#defineMRC ADDRESS_UN RESOLVABLE 0x00000005 
#define MRC_DEVICE_NOT_OPERABLE 0x00000006 
O #<jefine MRC DEVICE POWERED OFF 0x00000007 
& #defineMRC UNIMPLEMENTED (MRC_BASEERR+0x01) 
^ #define MRC.NOT ENOUGH_MEMORY (MRC BASEERR+0X02) 
Ni #define MRC_AIRDROME NOT_REGISTERED (MRC_BASEERR+0x03) 
W #define MRC AIRDROMEJiNABLE_TO_START (MRC_BASEERR+0xO4) 

#define MRC~AIRDROME_NOT_RUNNING (MRC_BASEERR+0x05) 
Q #define MRC_AIRDROME__NO_EVENT (MRC_BASEERR+0x06) 
M #define MRC A1RD ROM E_REQUEST_FAI LURE (MRC_BASEERR+Ox07) 

#define MRC~AIRDROME EXWAIT_FAILURE {MRC 8ASEERR+0x08) 
M #define MRC~AIRDROME~REQUEST TIMEOUT (MRCBASEERR+0x09) 
Q #define MRC_PIPE_OPEN_ERROR (MRC.BASEERR+OxOa) 
U #define M RC_S YSEV ENT_[c REATIO N (MRC_BASEERR+0xOb) 
in #define MRC_SYSTHREAD_CREATION (MRC_BASEERR+Ox0c) 
& #define MRC WRONG_CALL_SEQUENCE (MRC_BASEERR+0x0d) 
#defineMRC EVENT_SET FAILURE (MRC BASEERR+OxOe) 
#define MRC_EVENT_WAlf .FAILURE (MRC BASEERR+OxOf) 
#deftneMRC EVENT RESET FAILURE <MRC_BASEERR+0x10) 
#define MRC_MUTEX LOCK FAILURE (MRC_BASEERR+0x1 1 ) 
Wefine MRC_MUTEX_RELEASE FAILURE (MRC BASEERR+0x1 2) 
#defineMRC BUFFER_TOO_SHORT (MRC BASEERR+0x13) 
^define MRC_AIRDROME NO_PROCESS_POOL (MRC_BASEERR+0x14) 
#define MRC_PROCESS_ALREADY_ATTACHED (MRC_BASEERR+Ox15) 
#define MRC_PROCESS PIPE_CREATION (MRC_BASEERR+0x1 6) 
#define MRCJ>ROCESS~WAS_NOT ATTACHED (MRC BASEERR+0x17) 
#define MRC_UNKNOWN REQUEST^ CODE (MRC BASEERR+0x18) 
#define MRCAIRDROME_NOT_CONNECTED (MRC_BASEERR+0x19) 
#define MRC_AIRDROME_PIPE_ERROR (MRC_BASEERR+0x1 a) 
#defmeMRC ALREADY EXIST* (MRC_BASEERR+0x1b) 
#defme MRC~NO_INTERNAL_QUEUE (MRC_BASEERR+0x1 c) 
#deftne MRCJNTERNAL_OUEUE_ERROR (MRC BASEERR+0x1d) 
#define MRC_WRONG_ADDRESS (MRC_BASEERR+0x1e) 
ttJefine MRC WRONG SOCKET <MRC_BASEERR+0x1f) 
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Wefine MRC_NOT_OVERLAPPING INTERVAL (MRC BASEERR + 0x20> 
Wefine MRC_EVENT_SUPPRESSED (MRC 8ASE^R + 0y7i? 

#define MRC_UNKNOWN_CABLE TYPE MRC BAsIIrrS 
Wefire MRC.UNKNOWN.FRAMfT TYPE (MRC BASEERrS 
Refine MRC.UNKNOWN.LINK TYPE (MRC BASEERrS ' 
Adeline MRC_NO_TARGET CABLE (MRC BASEERR+0v3ri 
define MRC_NO_PARENT~ (MRC BASEERR^d^ ^ 

define MRC.WRONG.SEQUENCE (MRC B^EE^0x2 e » 
define MRC_NO_FRAME (MRC BASEBRR+0x2fl 

define MRCJJNKNOWN SERVICE (Mfit B^KRR^O! 

define MRC_WRONG_FRAME_FORMAT (MRC BASEERR+O*^ 
define MRC_NOT_SUPPORTED (MRC BASEErST ' 

^ N °™NG-TO_SEND (MRC bXsEERR^, 
Sdefme MRCJJNKNOWN (MRC BASEERRtO*V» 

define MRC.WRONG_MOB_FORMir (MlffB«ElRR + 0x36. 
define MRC.INCOMPLETE DATA (MRC^SEERRKta37^ 
define MRC.ALLPORTSINUSE (MRC B^EERrS ' 

WeflneMRC.LOCAL.MADDR.UNKNOWN (mIc ^B«EERR + 0x39. 
#d«fine MRC_WRONG_PORT ( MRC BASEERW«Ma> 

define MRC_NO_RADIO_UN(TS (MRC BASEERaSSb) 
define MRC_NO_ROUTERS (MRC BASEERR*0x3c> ' 

define MRC_OEVICE_NOT READY WCBKKR^L* 

£? e H S MJECT (mrcUase^r E S)° x 

#define VRC_RADIO_UNIT_NOT_ASSIGNED (MRC BASEERR*0x3n 
define MRC_ALREADY_ASSIGNED (MRC B^EERR^m ° 
ttefine MRC.ADDRESS.UNDEFINED (MRC BAsIS^ , 
#define MRC_NO_DATA (M RC BASEERrS ' 

#define MRC_MADDRESS FORMAT (M^C BASEERR+0x43) 
Wefjne MRC_PACKET_FORMAT (MrTb^TerrS) ' 



(MRC_BASEERRt0x45) 
(MRC_BASEERR+0x46) 
(MRC_BASEERR+0x47) 

(MRC_BASEERR+0x48) 
(MRC_BASEERR+0x49) 



#deflne MRC_SELF_ADDRESSING 
Wefine MRC_INACTIVE_SERVICE 
Wefine MRC_CYCLIC ROUTING 
#define MRC_ROUTER UNKNOWN 
#deflne MRC DISCONNECTED ii\ 

Mefine MRC.NETWORKUNREACHABLE "(MRC BASEERR+o*4al 
#define MRC_NORESPONCE (MRC BASEERrIox^M ' 

#define MRC^SHUTDOWNED (MRC~BASEM^an 
#define MRC.OUTOFCOVERAGE ScM^SSL) 
#deflne MRC_NO_DEVICE_ADDRESS (MTO^SSffii ) 
#define MRCDLL_LOAD ERROR ™~V_ tw weeRR+gx51 ) 

#define MRC_SELF ADDRESS UNKNOWN 
#if Idefined ( UNDER.CE ) 

#define MRCJNFONOSUPPORT (MRC_BASEERR+0x54) 



(MRC_BASEERR+0x52) 
(MRC_BASEERR+0x53) 
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#deflne MRC JNF0MASKEDOUT 
^define MRC_NEWINFOITEM 
#deftne MRC UPDATEDINFOITEM 



(MRC_BASEERR+0x55) 
(MRC_BASEERR+0x56) 



(MRC_BASEERR+0x57) 



#define MRC_NONEWINFO 
Wefine MRCJMOHOSTNAME 



(MRC_BASEERR+0x58) 
(MRC_BASEERR+0x59) 



#endif 

#define MRC_SHUTDOWNEDBYUSER (MRC_BASEERR+0x5a) 
#define MRC_UNSUFFICIENT_AD DRESSING (MRC_BASEERR+0x5b) 
JWefine MRC_AMB!GUOUS_HOST_ADORESS (MRC_BASEERR+0x5c) 
#define M RC_WR ON G_P ARAM ETE R (MRC_BASEERR+0x5d) 

// Begin 

#defineMRC SOCKETS_LIMIT_EXHAUSTED (MRC_BASEERR+0x5e) 
//End 

// following are return codes from the internal threads 

// they could be used on a system level but not on an methods return 

// code level 

#define MRC.BASECODE 0x00021000 



£ #define MRCTHR.SUCCESSFULL 0x00 

& #define MRCTHR_WAIT FAILURE (MRC_BASECODE+0x01 ) 

U #define MRCTHR_WAIT_TIMEOUT (MRC.BASECODE+0x02) 

^ #define MRCTHR WAIT ABANDONED (MRC_BASECODE+0x03) 

Li! #define MRCTHR~WAIT~UN KNOWN (MRC_BASECODE+Ox04) 

m #define MRCTHR_NO_EVENT (MRC_BASECODE+0x05) 



#endif 
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// Copyright© 1997 Dynamic Mobile Data, Inc. All rights reserved. 
// MSocketErrors.h 

// 

// Mobile Socket Error codes specification 

// 

m Idefined ( _MSocketErrors__ ) 
#define MSockelErrors 

include "MSocketCodes.h" 

LPCTSTR MSocketErrText(unsigned long code); 



#endif 
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What is claimed is: 

1. A method of operating a computer system for managing 
and controlling wireless devices comprising: 

(a) providing at least one wireless device connected to a 
first computer of the computer system; 5 

(b) providing a multi-tasking operating system having a 
base shell and base communications API to the first 
computer, said base shell of said operating system 
providing a base graphical-user interface (GUI) dis- 
playing GUI elements on a user desktop, said GUI 10 
elements including a control panel folder containing 
icons representing configuration controls of said oper- 
ating system; 

(c) providing a wireless control subsystem to the first ^ 
computer including a shell extension module extending 
said base shell of said operating system through pro- 
viding a first set of COM objects configured to provide 

a folder icon in said control panel folder containing 
device icons therein representing said wireless devices 
and a program icon in said control panel folder for 
accessing controls of said wireless control program 
subsystem by selection of said program icon; and 

(d) actuating the first computer by said wireless control 
subsystem such that said COM objects are used by said 25 
wireless control program subsystem to display graphi- 
cal indicia to said base shell of said operating system 
indicating activation of said wireless control program 
subsystem. 

2. The method of claim 1 wherein said first set of COM 3Q 
objects are configured to place an additional program icon 
on said user desktop. 

3. The method of claim 1 wherein said first set of COM 
objects are configured to display representations of said 
wireless devices folder and program icon in an exploring 35 
window. 

4. The method of claim 1 wherein said user desktop 
includes a task tray region for displaying icons representing 
programs that extend said operating system and wherein said 
first set of COM objects are configured to locate a program 4Q 
icon in said task tray region upon activation of said wireless 
control subsystem. 

5. A method of operating a computer system for managing 
and controlling wireless devices comprising: 

(a) providing at least one wireless device connected to a 45 
first computer of the computer system and at least one 
wireless-related application running on the same com- 
puter; 

(b) providing a multi-tasking operating system having a 
base shell and base communications API to the first 50 
computer; and 

(c) providing a wireless control subsystem to the first 
computer including: 

(i) a shell extension module extending said base shell of 
said operating system through providing a first set of 55 
COM objects used by said wireless control program 
subsystem to display graphical indicia to said base 
shell of said operating system indicating activation 

of said wireless control program subsystem, 

(ii) a programming module extending said base com- 60 
munications API through a set of programming 
objects callable by wireless-related applications for 
enabling wireless communications among said wire- 
less device and said wireless-related applications, 
and 65 

(iii) a system module comprising a plurality of linked 
programming objects operative to propagate infor- 
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mation indicative of an occurrence of system level 
events related to at least one of the operation and 
status of said wireless device through said linked 
programming objects of said system module to said 
programming objects of said programming module 
and then to said at least one application running on 
the first computer. 

6. The method of claim 5 wherein said wireless control 
subsystem further comprises an industry standard module 
which exposes one or more industry -standard programming 
interfaces to a programmer to enable development of custom 
wireless applications which can communicate with said 
programming module and said system module. 

7. The method of claim 6 wherein said one or more 
industry-standard programming interfaces comprises 
ActiveX. 

8. The method of claim 6 wherein said one or more 
industry-standard programming interfaces comprises Win- 
sock. 

9. The method of claim 6 wherein said one or more 
industry-standard programming interfaces comprises 
OBDC. 

10. The method of claim 5 wherein said programming 
objects of said programming module includes application 
socket objects which represent single socket connections 
with each application, and said plurality of said linked 
programming objects include a first layer of cable objects 
representing a communication link with a wireless device, a 
second layer of socket objects representing a user created 
socket connection, and a third layer of process objects 
representing the link between the system module and the 
programming module, and said wireless control subsystem 
actuates the first computer to: 

(i) sense at said cable objects the occurrence of a system 
level event related to the operation and/or status of said 
wireless device, 

(ii) send first signals from said cable objects indicative of 
said system level event to said socket objects, 

(iii) send second signals from said socket objects indica- 
tive of said system level event to said process objects, 

(iv) send third signals indicative of said system level 
event from said process objects to said application 
socket objects of said programming module, and from 
said application socket objects to the application. 

11. The method of claim 10 wherein said system module 
is operative to propagate through said objects a system level 
event indicative of when said at least one wireless device is 
in an out-of-coverage area. 

12. The method of claim 11 wherein said wireless control 
subsystem is configured to hold in abeyance communica- 
tions with a said wireless device determined to be in an 
out-of-coverage area until said system module determines 
when said at least one wireless device returns to a coverage 
area by sensing the occurrence of an in-coverage system 
event. 

13. The method of claim 10 wherein said system module 
is operative to propagate through said objects real-time 
system level events to provide diagnostic information about 
the status of said at least one wireless device. 

14. The method of claim 13 wherein said real-time 
diagnostic information is displayed on a display device of 
the first computer in an on-screen diagnostic panel. 

15. The method of claim 14 wherein said diagnostic 
information includes registration status, signal strength and 
device address. 

16. The method of claim 5 wherein said system module 
further comprises at least one wizard program for automatic 
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fJL™ 6 1"! th ° d ° f ° laim 11 ' wherein *e computer system 

cornmumcate snnultaneously with said a. least oneTpX - 

™«uns i on Mid first computer to commumcate wto wo ™ 
more of satd wireless devices simultaneously. W " h tW ° 01 

f Jh ° d ° f Ckim 19 ' whercia computer system 

further zncludes a second remote computer JT£X 
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weless-related application running on the second remote 
computer, said second remote computer having a Zem 
module and being connected to the first comJuL 
communtcaUons link, and said wireless control subsystem i 

said second remote computer to communicate with two or 
more of satd wireless devices simultaneously 

21. The method of claim 5 wherein said at least one 
wireless device comprises at least one wire s d vie 
operable with a first wireless network protocol and afte 
on wireless device operable with a second, differ! w Z 
less network protocol. 

22. The method of claim 5 wherein said system module 
uuhzes sockets for data transport. 

23. The method of claim 5 wherein said wireless devices 
are assrgned a unique numeric address, and wrTrcin laid 
system and shell extension modules are operant toma^ 
sa,d numenc addresses to user-friendly monikers 
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